Re: [patch 1/4] mempolicy: convert MPOL constants to enum

[Paul Jackson <pj@sgi.com>]

> I do not subscribe to the theory that just because we have a couple extra 
> bytes of space somewhere in struct mempolicy that we have to use it 
> immediately.

Good grief ... I'm not lobbying for separate flag fields because the
space is there.  I was just dealing with one possible obection, by
noting that it wouldn't cost us in terms of struct mempolicy size.

> It makes the kernel code simpler, in a way.
> 
> Now we only have to pass a single actual among functions that include both 
> the mode and optional flags (there are a lot of them and they span not 
> only the VM but also filesystem code).

This gets closer to the key issue.

We both agree we want "simpler", but disagree on what that means.

We don't measure complexity -solely- by counting the size of parameter lists.
If we did that, we'd be packing all manner of sub-integer fields into single
'int' parameters.

I tend to measure complexity a level up from the bits and bytes,
and more in terms of how I think about things.  If I think of a routine
as taking two values, such as in this case an mempolicy mode (such as
MPOL_BIND or MPOL_INTERLEAVE) and this new flag (MPOL_F_STATIC_NODES),
which have a different sort of affect.

==> If each time I look at some 'flags' field, I have to think of it
as a couple of things glued together that I will have to pick apart to
use, that's more mental work than seeing those two things explicit and
separate, through most of the mempolicy.c code <==

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214