Yup. Sorry ... beating dead horses is too much fun.
I disagree, though I risk being in a minority on this matter.
Yes, you're entirely correct that these new flag have to be passed to and
from user space via an existing integer parameter. There is no plausible
way other than packing the new flags into that existing parameter to preserve
the kernel-user API.
However, once inside the kernel, how we store this flag in struct mempolicy,
and how we pass it about between kernel routines, is our choice.
We can leave it packed, and unpack and repack it each time we consider the
flag and mode bits, or we can store and pass it as separate flags.
I urge us to consider handling it as separate flags within the kernel
because it most clearly and explicitly represents what is going on logically.
There are two different kinds of flags here, the original mempolicy modes,
and these meta modes (MPOL_F_STATIC_NODES, being the first example) which
affect the nodemask intepretation.
Cramming both these into a single int is necessary across the kernel-user API,
but it's an obfuscation that is not needed, therefore better avoided, within
the kernel code.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
