I've already made the change in my patchset as a result of Christoph's
comment.
I disagree, that space can be reserved for future use that will perhaps be
much needed at that time.
The type 'short' is obviously overkill to hold the value of the policy
mode since we only have four currently defined modes. We'll never exceed
the capacity of type 'unsigned char' if mempolicies are going to remain
useful.
If the flag bits are going to be stored in the same member as the mode, it
is necessary to make the change, as I have, to be unsigned to avoid
sign-extension when this is promoted to 'int' that is required as part of
the API.
The problem with your approach is that we need to pass the optional mode
flags back to the user through get_mempolicy() and the user needs to pass
them to us via set_mempolicy() or mbind(). So we'll still need the
#define in linux/mempolicy.h:
#define MPOL_F_STATIC_NODES (1 << MPOL_FLAG_SHIFT)
We could deal with this as follows:
if (mode & MPOL_F_STATIC_NODES)
pol->mode_f_static_nodes = 1;
but that doesn't make much sense.
Once Christoph's comment is taken into consideration and we start passing
around 'int policy' instead of 'enum mempolicy_mode mode' again, I don't
think anybody will struggle with doing:
if (mode & MPOL_F_STATIC_NODES)
to check for the prescence of a flag.
David
--