> 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 <[EMAIL PROTECTED]> 1.940.382.4214 -- 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/