Re: Linus 2.6.23-rc1

[Ingo Molnar]

* George Sescher <gesacs@xxxxxxxxx> wrote:

> > * George Sescher <gesacs@xxxxxxxxx> wrote:
> >
> > > > > On 30/07/07, Ingo Molnar <mingo@xxxxxxx> wrote:
> > > > > > i'd encourage you to do it - in fact i already tried to prod Peter
> > > > > > Williams into doing exactly that ;) The more reality checks a
> > > > > > scheduler has, the better. [ Btw., after the obvious initial merging
> > > > > > trouble it should be much easier to keep SD maintained against
> > > > > > future upstream kernels due to the policy modularity that CFS
> > > > > > introduces. (and which policy-modularity should also help reduce the
> > > > > > size and complexity of the SD patch.) ]
> > >
> > > > * George Sescher <gesacs@xxxxxxxxx> wrote:
> > > > > <chuckle>
> > > > >
> > > > > You're advocating plugsched now?
> > >
> > > On 30/07/07, Ingo Molnar <mingo@xxxxxxx> wrote:
> > > > hm, the way you posited this question implies that you see an
> > > > inconsistency in my position or that it surprised you - i cannot explain
> > > > the '<chuckle>' in any other way :) Which bit do you see as inconsistent
> > > > and/or which bit surprised you and why?
> > >
> > > The idea is not good enough for mainline and has no place in mainline
> > > yet you say it's very important to maintain it... but out of mainline.
> > > Place the responsibility of keeping mainline's performance in check
> > > "reality check as you called it" on to someone who is forced to
> > > develop out of mainline? I have zero interest one way or the other
> > > myself, but how can one not chuckle?
> 
> On 30/07/07, Ingo Molnar <mingo@xxxxxxx> wrote:
> > What you should realize is that _all_ future code that goes into Linux
> > is 'forced' to be developed 'out of mainline' today. So what you seem to
> > characterise via negative terms like 'forced', and what seems to make
> > you 'chuckle' (not meant as a compliment either i gather ;), is in fact
> > the _very engine_ that keeps Linux running.
> >
> > And there's no exception: Linus himself creates an "out of mainline"
> > fork of Linux every time he develops something new. "Forks" are _the_
> > main mechanism to develop Linux, and it always was. External code is the
> > "reality check" of mainline code. It is the 'external pool of genes'
> > that is _competing_ against in-tree code.
> >
> > Sometimes the decision to include new bits of code is easy and positive
> > (so it is a "fork" only very briefly and nobody actually ever has enough
> > time to think of that code as a "fork"), sometimes it takes some time
> > and the decision is positive, sometimes the decision is immediately
> > negative and the code is rejected, sometimes it's negative after some
> > time. Often code goes through several cycles of rejection before it is
> > merged. The larger the code, the more rejections it will see - and that
> > is natural. Sometimes, very rarely, out of the hundreds of thousands of
> > external changes that went into Linux so far, code seems to be staying
> > 'in limbo' forever - such as the kernel debugger. So _every_ color of
> > the spectrum is present: immediate integration, immediate rejection,
> > long-term integration, long-term rejection, ping-pong of rejections
> > until integration, and even decisions that seem to take a near
> > 'eternity' in very rare cases.
> >
> > If a biologist took a look at these gene pool dynamic parameters alone,
> > without knowing a squat about kernel technology, the likely conclusion
> > would be that this is "a healthy, diverse gene pool that is being
> > affected by many many external factors. A true expert at survival, that
> > critter!" ;-)
> >
> > For example, i'm at the moment maintaining in excess of 400 patches "out
> > of mainline", many of which will never see the "daylight of upstream".
> > Many of those are longer-term "reality checks" that could replace
> > in-tree code in the future or are in the process of replacing in-tree
> > code as we speak. Some are "reality checks" that _failed_ to replace
> > in-tree code but i'm still maintaining them because i find them useful.
> > If the kernel code that these patches modify happens to be modularized
> > then it is sometimes helpful to my out-of-tree patches (and sometimes
> > it's a pain) - but in any case, i dont "require" nor "suggest" upstream
> > maintainers to modularize, just to make my "out of tree" life easier.
> > Are they still useful to Linux in general? I sure hope so.
> >
> > It was always like this in Linux: modularization is mainly dictated by
> > the needs of the in-tree code - and that's very much on purpose, and
> > always was, to increase the advantages of including good external genes
> > in the kernel gene pool.
> 
> <permission to jump down my throat granted now>

heh :) Sorry, but i have to disappoint you on that count :-)

> Nope. I can't equate your soliloquy about the development process with 
> what it appears you are doing in the case of plugsched [...]

could you please be a bit more specific - what do you mean under "what 
you are doing in the case of plugsched"?

In the above section which you characterised as 'soliloquy' (i guess i 
must have failed to make myself clear enough) i tried to answer the 
statement you articulated:

> > > Place the responsibility of keeping mainline's performance in 
> > > check "reality check as you called it" on to someone who is forced 
> > > to develop out of mainline? [...]

by pointing out that "developing out of mainline" (such as PlugSched or 
like the 400+ patches i maintain out of tree), is not something negative 
as you seem to have suggested/implied but the main mechanism of Linux 
development - so not surprisingly, while i might disagree whether 
something out of tree should go upstream or not, i dont disagree with 
the idea of keeping out-of-tree patches - why should i? I do it myself 
and always did it. Or in other words: without out-of-tree patches the 
kernel 'pool of genes' would become stagnant.

If you disagree with me or if you have any other questions then feel 
free and let me know. And as always, i could be mistaken so dont expect 
me to "jump down on your throat" in any way, shape or form :-) Thanks,

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/