* Bill Huey <[EMAIL PROTECTED]> wrote: > Here's the problem, *a lot* of folks can do scheduler development in > and outside community, so what's with exclusive-only attitude towards > the scheduler ?
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 - 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/
