On Mon, 25 Feb 2008, Paul Jackson wrote:
> +enum {
> + MPOL_DEFAULT,
> + MPOL_PREFERRED,
> + MPOL_BIND,
> + MPOL_INTERLEAVE,
> + MPOL_MAX, /* always last member of enum */
>
> Aren't the values that these constants take part of the
> user visible kernel API?
>
> In other words, if someone added another MPOL_* in the middle
> of this enum, it would break mbind/set_mempolicy/get_mempolicy
> users, right:
>
> +enum {
> + MPOL_DEFAULT,
> + MPOL_PREFERRED,
> + MPOL_YET_ANOTHER_FLAG, /* <== added flag ... oops */
> + MPOL_BIND,
> + MPOL_INTERLEAVE,
> + MPOL_MAX, /* always last member of enum */
>
I don't suspect that a kernel developer is going to make such an egregious
error. The user would need to be using a new linux/mempolicy.h with an
old kernel to get the wrong behavior.
> I'm thinking that we should still specify the specific value
> of each of these flags, by way of documenting these necessary
> values, as in:
>
> +enum {
> + MPOL_DEFAULT = 0,
> + MPOL_PREFERRED = 1,
> + MPOL_BIND = 2,
> + MPOL_INTERLEAVE = 3,
> + MPOL_MAX, /* always last member of enum */
>
That looks overly redundant to me and doesn't protect against adding
MPOL_YET_ANOTHER_FLAG in the middle of preferred and bind to get two mode
values with the int value of 1.
David
--
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/
