lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/4] mempolicy: convert MPOL constants to enum
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 <pj@sgi.com> 1.940.382.4214


\
 
 \ /
  Last update: 2008-02-13 03:25    [W:0.099 / U:2.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site