Re: Linus 2.6.23-rc1

[Ingo Molnar]

* 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?

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.

	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/