Messages in this thread | | | Date | Wed, 2 Apr 2008 01:20:06 -0500 | From | Paul Jackson <> | Subject | Re: [PATCH 0/3] x86: add cpuset_scnprintf function |
| |
Hmmm ... my apologies, Mike, if I overlooked some earlier discussion of this patchset on one of the other more limited email threads that we share ... however a couple of aspects of this patchset don't fit so well for me. 1) I'm surprised to see this new routine called 'cpuset_scnprintf' (with the "cpuset" prefix), rather than a variant of a trio of names with prefixes of bitmap_, cpumask_, and nodemask_, like the other print routines in the bitmap family. This doesn't seem to be a cpuset function to me, but a bitmap (and derived types cpumask and nodemask) printing function. 2) The idea of the patch, that being a kernel modal flag that if set, changes a few particular details of the kernel API for all, seems like something I'd rarely want to do, unless I was really short of other options. It leads to one app breaking another as a result of changing this mode, and to head butting between apps which cannot agree on how to set the mode. And it introduces the option of breaking an existing API, which is seldom a good option.
I tried reading the opening "discussion that led up" comments you posted, but couldn't find any overwhelming problem that had to be solved of sufficient magnitude and quandry of sufficient difficulty to justify the API conflicts and breakage in (2) above. I did find this comment, apparently by Bert Wesarg (though that's not clear from your presentation):
> If you change the format, the brown-paper-bag is yours.
I don't see a compelling response to the above comment.
Granted, what you've done isn't outright changing the format. Rather it is handing user space a means to change the format system-wide.
However doing this is worse in my view than simply breaking the format outright, unilaterally and irrevocably. If you just flat out stick a fork in an API and break it hard on some release, then at least user space knows that it must adapt or die at that version. If you hand user space the means to break that API, then any properly and defensively written user code has to be prepared to deal with both API flavors, and the majority of user space code is broken half the time, when run on a system with the API variant it wasn't expecting. More over, you end up with apps having "toilet seat wars" with each other: you left it up and it should be down; no you left it down and it should be up. Not a pretty sight.
Perhaps I totally misunderstand this patchset ?
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |