You came to us as an ex-BSD developer (which has a completely different
contribution culture) and early on i tried to explain to you (and we met
in person at OLS2004) that the Linux way of getting code upstream is not
that of social-engineering or talking the code upstream, but that of
_coding_ your stuff upstream: working with others and getting good code
accepted. I'm not sure you ever realized that point.
To counter your myth of "upstream development exclusivity", here are
some git-provided hard numbers. Since 2.6.22 was released 3 weeks ago,
over half a million lines of code were added/modified/removed in the
upstream -git kernel:
5965 files changed, 332689 insertions(+), 269500 deletions(-)
that massive amount of work was done by over 750 contributors. Out of
those 750 contributors, more than 160 are _first time contributors_.
Think about it, there's _lots_ of fresh blood, about 650 new kernel
contributors a year. The kernel/sched.c file itself, with 274 commits
and 88 unique contributors over the past ~2 years alone is one of the
most actively and most diversely developed core kernel subsystems in the
kernel.
Regarding PlugSched, i'd suggest you to read the detailed explanation
that has been offered in this and in related discussions over the past
few years on lkml. (see: http://lkml.org/lkml/2007/4/15/124 and
http://lkml.org/lkml/2007/4/15/64 and many other postings)
To recap: we dont have a pluggable TCP/IP core either. Nor do we have a
pluggable MM. Pluggable I/O schedulers are not an unconditional success
either - Nick (I/O scheduler author) recently stated that and suggested
the CPU scheduler to not be pluggable.
Whether something becomes pluggable or not depends on many
_technological_ factors but you appear to be dead-set on spinning _any_
technical decision against pluggability into a conjured-up non-sequitor
non-technical "so this means you have an exclusive-only attitude"
position.
Why do you do that? Why cannot you accept the plain fact that:
_in a kernel, some things should not be pluggable_
Simple as that. I am still in favor of PlugSched as a nice external
patch because it keeps people interested in schedulers and keeps the
competitive pressure up even higher (and other reasons), but there are
_stronger factors than that_ against its inclusion into mainline. (see
those many mails about those factors)
Besides the technological advantages, the competitive pressure can be
_even higher_ if the 'competition' is not in-tree but out-of-tree - and
the end result is an ultimately better scheduler. Had we not rejected
PlugSched 4 years ago CFS could easily never have happened. We'd have
2-3 mediocre schedulers, instead of one good scheduler and _users_ would
resist the removal of any of those schedulers, so no clear winner could
ever gain enough momentum and Linux would forever be stuck with a stupid
and inferior "you have to tweak the scheduler selection manually to your
workload to get the max out of the system" handicap.
But ... i can also understand it that you as a _person_ are unhappy:
You were quite unhappy and bitter about me not including your lockstat
patch in -rt, while all that happened was that for months i (and others)
told you that the lockstat idea is nice and sound and tried to point it
out to you how much simpler and more elegant it would be to use the
lockdep infrastructure for the same purpose and tried to encourage you
to pick that route. Peter Zijlstra implemented that approach meanwhile,
and he used around a magnitude less code than your patch did. That code
is upstream now. _You_ could have been the one who did that, and it was
you who prevented yourself from having done that major contribution to
Linux lock instrumentation.
Perhaps partly influenced by your negative lockstat experience, you were
also the first one who brought up the (pretty bogus) "elitist" "old
guard" argument [ http://lkml.org/lkml/2007/4/14/115 ] as a reply to my
initial CFS announcement, and shortly after your mail Con wrote his
infamous outburst against CFS [ http://lkml.org/lkml/2007/4/14/199 ], to
which you came up with another bogus "the main failure I see here is
that Con wasn't included in this design or privately in review process"
reply [ http://lkml.org/lkml/2007/4/15/4 ] that only fanned the flames.
I believe by doing so you poured the oil of your own bitterness on his
fire, thinly masked as neutral constructive criticism.
So in my opinion you are far from being an unbiased observer in this
matter, you keep repeating your old arguments without apparently
listening to the replies and thus i doubt anything i say could really
make you 'happy' :-/
Really, i'd love it if you started contributing to Linux in a major way,
instead of doing what seems to amount to stirring up personal
controversy, and i believe the only inhibitor to such positive kernel
contributions is _yourself_. If you spent half of the energy you are
spending on writing these emails on producing actual code you could have
become a maintainer of some nice Linux subsystem easily. (as many other
people have become that who came to Linux much later than you) That door
is still not closed of course, and i believe it all only depends on you,
not on any upstream maintainer.
Ingo
-
