David wrote: > The enum has already been removed, as I've said a few times.
Yup. Sorry ... beating dead horses is too much fun. > The 'flags' field would be wrong because you're ignoring that these flags > are both passed by the user to the kernel and by the kernel to the user as > part of the 'int *' parameter in either set_mempolicy() or mbind(). 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 <[EMAIL PROTECTED]> 1.940.382.4214 -- 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/