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
> 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


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