So many kernel 2.6.x branches!

On Saturday 17 October 2009 01:37 in comp.os.linux.setup, somebody
identifying as Marco A. Cruz Quevedo wrote...

[Follow-up set to comp.os.linux.setup due to the fact that I have a
killfilter on G2 posts for comp.os.linux.misc in response to that group
being targeted by spammers.)

> Hi everybody,
>
> I am just wondering, why are there so many 2.6.x stable brances? why
> there is no 2.7 or even 2.8? Will there ever be 3.0?

Well, in reply to your first question, the 2.6 kernel generation keeps
on evolving, but as some developments in newer kernels may cause
problems on some older hardware because of specific "quirks" of that
hardware, earlier stable kernel releases are still kept available.

In addition to this, the whole range of stable kernels is also kept
available for historic reasons, and because certain specialized
projects apply patches to certain kernels - e.g. Xen, OpenVZ, et al -
which themselves are regularly updated but which are kept consistent
with a particular kernel version, and so those developers need access
to those previous stable kernel releases.

Now, the above pertains to the vanilla kernels as released by Linus and
friends, but then there is the level of the distribution releases.
When a new release of a distribution is being developed, they generally
pick the most recent stable kernel available from kernel.org - i.e. the
vanilla kernels from Linus - and take it from there, adding patches of
their own - some which fix bugs or patch security holes, some which add
extra functionality (but might jeopardize security), et al - and
building their entire operating system distribution against that kernel
version.

Further development of the distribution release then focuses on bringing
everything together to a stable operating system release, but of
course, in the meantime, Linus and friends keep on working on the
upstream kernel, and so by the time a particular distribution is
released to the public, there may already be a newer vanilla kernel
from Linus than the kernel featured in the distribution.

As for your question regarding higher kernel numbers, Linus has from day
one adopted a versioning scheme in which odd kernel versions were
considered "unstable" - i.e. for development only - and the even kernel
versions being reserved for stable production kernels. So before 2.6
came along, the stable kernel would be 2.4.something, with
2.5.something being the development branch that would eventually lead
to the stable 2.6.x branch.

As of 2.6 however, the odd number versioning for development kernels has
ceased, and instead development kernels are now given a special suffix
to indicate what kind of kernel it is and to distinguish them from the
stable kernel. The really new and untested stuff also goes into
separate branches of the GIT development tree, keeping the mainstream
2.6 tree clean from insufficiently tested stuff.

The development of the Linux kernel keeps going on, of course, but so
far Linus has seen no reason to even think of a 2.8 generation - for
which the 2.7 generation would then be the development branch - as
everything that's currently applicable or foreseeable in terms of
hardware development or kernel innovation is still covered by the 2.6
kernel generation API.

As for your question regarding a 3.0 branch, that is yet again another
distinction. Even if there were ever to come a 2.8 kernel generation
and then even a successor to that one, then this successor would
eventually be a 2.10 generation - and then possibly even 2.12 and 2.14,
and so on - but not a 3.0 generation. In order to understand that, you
have to understand the history of the Linux kernel.

The very first Linux kernel was given version 0.something while it was
still under development, and when Linus finally released his first
stable kernel, it was versioned 1.0. However, this was a kernel in the
old UNIX tradition, which had all of the drivers built statically into
the kernel image, and if you wanted to add a driver which was not
available in the sources tree (and thus in the eventual binary kernel
image after compilation), you had to recompile the whole kernel from
sources. Such a kernel would definitely also not be usable with
proprietary drivers because of their binary-only nature.

This is why Linus ended up developing a 2.x design. 2.x can be used
with drivers which are statically built into the kernel image itself as
well as with separately built driver modules that can be loaded into
the kernel and unloaded from it again. This allows third-party
developers to write driver modules for the kernel which are not
supplied (or even approved) by Linus and the other kernel developers
themselves. For instance, video adapter manufacturers like nVidia
refuse to open up the source code for their drivers, but Linux now
allowing the loading of driver modules then still allows one to load a
proprietary nVidia driver into the kernel.

So the difference between Linux 1.x and 2.x is just this: a major
overhaul of the kernel API to allow the ability to use drivers which
are either statically built into the on-disk kernel image or which are
built as loadable modules for the 2.x branches, versus the solely
statically linked drivers in the 1.x branches. It is therefore
unlikely that there would ever be an evolution prompting Linus Torvalds
to bump up the kernel to a 3.x branch, since that is not just a
generation bump but an actual kernel design bump.

--
*Aragorn*
(registered GNU/Linux user #223157)