On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
> > Yeah, it gets tricky. I'm not too sure about only pulling the mode and
> > flags apart at mpol_new() time because perhaps, in the future, there will
> > be flag and mode combinations that are only applicable for set_mempolicy()
> > and not for mbind(), for example. I can imagine that someday we may add a
> > flag that applies only to a task mempolicy and not to a VMA mempolicy.
>
> True. Altho' at such a time, I'd probably argue for testing for and
> rejecting invalid mode/flag combinations in the respective
> functions :-).
>
Yeah, and that would require the modes and flags to be split apart in
sys_set_mempolicy() and sys_mbind() or at least in do_set_mempolicy() or
do_mbind(). So if we see the possibility that we want to test for mode
and flag combinations that perhaps differ between the set_mempolicy() and
mbind() case, we have to do it in either of those two places. I think we
should do it there, as early as possible, like I did in my first patchset.
> OK. I'm "caving"... :-) Different views of consistency. But,
> eventually, I hope we can replace the separate mode[, flags] and
> nodemask in the 'sb_info with a mempolicy and keep the details of modes,
> flags, etc. internal to mempolicy.c.
>
I agree, I think keeping all of these implementation details inside
mm/mempolicy.c is the best practice. We'll still need to expose some of
the details, such as the parsing of '=static' in the tmpfs mount option to
add the MPOL_F_STATIC_NODES flag to the policy, but situations like that
should be rare.
For extendability, I agree that the struct shmem_sb_info member should be
a pointer to a mempolicy and not an int.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
