[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <df7d5b0833dba5a3af6cf66e090aedb6@lycos.com>
Date: Sat, 02 Apr 2016 17:43:47 +0500
From: "Artem S. Tashkinov" <t.artem@...os.com>
To: linux-kernel <linux-kernel@...r.kernel.org>
Subject: The most insane proposal in regard to the Linux kernel development
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
Powered by blists - more mailing lists