On Mon, 11 Feb 2008, David Rientjes wrote: > > The second paragraphs seems to indicate that such an approach does not > > work since we also use MPOL_xx constants to set flags in the memory > > policies? > > > > 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. Then you could follow through with the enum mempolicy thing throughtout. Why not use enum mempolicy in struct mempolicy? -- 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/
