On Mon, 11 Feb 2008, Christoph Lameter wrote:Not sure I'm understanding your question, sorry. Mempolicy modes have always been int constants because it doesn't make sense to combine them. Putting them into 'enum mempolicy_mode' leaves that unchanged. Mempolicy flags can be combined (even though my patchset only currently implements one, it's easy to implement others). So they definitely cannot be enum constants. Regardless, storing the policy (mode | flags) in struct mempolicy as a 'short' doesn't help since a negative policy doesn't mean anything. In preparation for allowing the upper MPOL_FLAG_SHIFT bits to be used to store the flags of this member, I converted it to 'unsigned short'. This is because the API with userspace is through 'int', which is implicitly signed, and we don't want to sign-extend the upper bit if it's ever used to hold a mempolicy flag. David --
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
