> * 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?
On 30/07/07, Ingo Molnar <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
