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
-
