The most insane proposal in regard to the Linux kernel development

From: Artem S. Tashkinov
Date: Sat Apr 02 2016 - 08:50:27 EST

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,