* George Sescher <[EMAIL PROTECTED]> wrote:
> > > On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > <chuckle>
> > >
> > > You're advocating plugsched now?
>
> On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
