Message-ID: <a12e280d0707300226y71d47b04t86000abb6a082c30@mail.gmail.com>
Date:	Mon, 30 Jul 2007 19:26:20 +1000
From:	"George Sescher" <gesacs@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Kasper Sandberg" <lkml@...anurb.dk>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"CK Mailinglist" <ck@....kolivas.org>,
	"Peter Williams" <pwil3058@...pond.net.au>
Subject: Re: Linus 2.6.23-rc1

> * George Sescher <gesacs@...il.com> wrote:
>
> > > > On 30/07/07, Ingo Molnar <mingo@...e.hu> 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@...il.com> wrote:
> > > > <chuckle>
> > > >
> > > > You're advocating plugsched now?
> >
> > On 30/07/07, Ingo Molnar <mingo@...e.hu> 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@...e.hu> 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>

Nope. I can't equate your soliloquy about the development process with
what it appears you are doing in the case of plugsched but you're
obviously too smart for me to argue against or I don't understand and
I've already overstepped my authority on this mailing list being an
ordinary user.  I'll just end up trying to extract your boot from my
anus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists