On Tue, 12 Feb 2008, Paul Jackson wrote: > ==> If each time I look at some 'flags' field, I have to think of it > as a couple of things glued together that I will have to pick apart to > use, that's more mental work than seeing those two things explicit and > separate, through most of the mempolicy.c code <== >
That doesn't logically follow because the aggregate of the mode and the optional flags _are_ the policy itself. If you want to know whether a policy is interleave, for example, and don't care whether it is referring to static (absolute) node ids, then you need to mask that off. The reality of the kernel code is that these policies are not only restricted to kernel/mempolicy.c. They are also shared with filesystem code that store them in a single member of a struct as well. The interface between those two are functions that would now need to be modified to include additional parameters to pass the flags along. Additionally, these flags need to be "glued together" with the mode in userspace to pass to the syscalls anyway, so they're facing the exact same challenge. So once this gets a little traction, I think it will quickly become the norm for how you think about the 'policy' member of the struct. 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/