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/