The most insane proposal in regard to the Linux kernel development

[Artem S. Tashkinov]

Hello all,

It's not a secret that there are two basic ways of running a Linux 
distribution on your hardware. Either you use a stable distro which has 
quite an outdated kernel release which might not support your hardware 
or you run the most recent stable version but you lose stability and you 
are prone to regressions.

This problem can be solved by decoupling drivers from the kernel and 
supplying them separately so that you could enjoy stable kernel version 
X with brand new drivers like it's done in most other proprietary OS'es. 
I've been thinking of asking Linus about this decoupling for years 
already but I'm hesitant 'cause I'm 99.99999% sure he will downright 
reject this proposal. Still I'm gonna risk asking 'cause there are 
multiple pluses with this proposal:

1) We might have truly stable really long term supported kernels (3-5 
years of more).
2) The kernel size will be reduced by two orders of magnitude.
3) The user will be free to try different kernel drivers versions 
without leaving his/her stable kernel.
4) Drivers will become easier to develop, debug and maintain (usually 
the developer will just have two kernel trees to target and test 
against).
5) There will be a sense of QA/QC and accountability (nothing like that 
exists at the moment as reflected by a very long list regressions for 
every kernel release).
6) Drivers regressions will be easier to spot ('cause you can be sure 
that no other kernel changes have had undesired consequences/conflicts - 
right now driver A might break and does occasionally break because 
unrelated feature B has been reworked/tweaked/etc.).
7) There will be a lot fewer kernel releases and no constant rush to 
update them.
8) Kernel release numbers will become meaningful again. Right now no one 
can quickly say what's the difference between kernel 4.5.0 and 4.1.0.

This way kernel development must be changed to accommodate this 
proposal:

1) Yeah, I know, you all hate that, but stable APIs and ABIs must be 
introduced and supported for, let's say, at least three to five years.
2) Like we used to have during 2.2.x, 2.4.x development cycles, unstable 
kernels with new APIs must be developed in parallel to stable ones.
3) Of course that means that drivers for every kernel tree 
(stable/unstable) must be developed in parallel. In the future, perhaps, 
several parallel drivers versions will have to be developed, e.g. 
drivers for kernels 1.0.x (stable), 1.2.x (next stable) and 1.3.x 
(unstable). However, taking into consideration that these three kernel 
releases span the range of 3..5 * 3 years = 9..15 years, older kernels 
will stop being supported eventually.

In short I'm offering a concept of Windows NT kernel development. They 
have very rare stable kernel releases (e.g. XP SP0, SP1, SP2, 2003, 2003 
R2 - all binary compatible), then Vista kernel began development and 
after its release six years later, hardware vendors had to support just 
two kernel releases. Not that is a big issue.

One very big justification of this proposal is that core Linux 
development (I'm talking about various subsystems like mm/ ipc/ and 
interfaces under block/ fs/ security/ sound/ etc. ) has slowed down 
significantly over the past years so radical changes which warrant new 
kernel API/ABI are less likely to be introduced.

Please, share your opinion.

--
Best regards,

Artem