Messages in this thread | | | Date | Tue, 12 Feb 2008 20:59:44 -0600 | From | Paul Jackson <> | Subject | Re: [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
| |