I had taken a vow of silence on this one, but couldn't resist one more
round.
David wrote:
True -- the necessary overloaded ugliness of the kernel-user system
call API is propogated throughout mempolicy.c. However, I wouldn't
necessarily call that an advantage.
... but does require the use of the new mpol_flags() and mpol_mode()
macros by code in mmshmem.c, outside of mm/mempolicy.c
This will cause a bug in the future, that escapes into the wild, when
someone forgets one of these. I'll bet on that. It's fragile, because
(1) such errors are easy to make, and (2) hard to catch.
Clear, robust code - that's the biggie.
True -- though by this argument, we'd routinely aggregate multiple flags
and small words into single integer parameters, just to minimize the
parameter count. Putting two flags in one parameter is a false
simplification, unless required by circumstance, such as communicating
with deep space probes or across the system call boundary with existing
API's.
Across the system call boundary, we have little choice, for compatibility
reasons. But kernel internal interfaces are not so constrained, and the
ugliness at the system call boundary can be quarantined from most of the
mempolicy.c code.
To be clear to others, as you know, we're not talking here about
growing the sizeof(struct mempolicy) at present, but rather about using
some currently unused bytes in the struct.
More often than not, when someone adds complexity that is not needed at
present, because it might be needed in the future, they are making it
harder to maintain the code, not easier.
The single most important thing we can do to improve future
maintainability of code is to make it more readable.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
--
