Revamped Linux Kernel Numbering Concluded

kernel_dan writes "Following on the heels of a prior discussion about a kernel numbering scheme, KernelTrap has the conclusion. From summary: "Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable.'" Torvalds suggested specific guidelines to alleviate burn-out of the .y maintainer and Greg KH volunteered to begin maintainership."

Gregkh already made one point release

[Xpilot]

You can find it in his own subdirectory on kernel.org at:

http://www.kernel.org/pub/linux/kernel/people/greg kh/v2.6.11/ [kernel.org]

It includes tiny fixes such as a Dell laptop keyboard fix and a raid6 compilation fix for ppc.

I wonder...

[Anonymous Cumshot]

If this will make Andres Salomon security & bug fixes patchset [rpi.edu] obsolete since it pretty much focuses on the same things that Linus wants to see for the 2.6.x.y releases..

FYI, Andres Salomon's patchset provides the foundation for Debian's kernels and has been discussed recently on kerneltrap here [kerneltrap.org] and here [kerneltrap.org].

Hopefully Andres Salomon will keep on going

[Anonymous Coward]

Hopefully Andres won't stop.

Linus only wants to put security patches and patches to bugs which cause a kernel hang or oops or compile failure to get into the 2.6.x.N patches:

- some very _technical_ and objective rules on patches. And they should
limit the patches severely, so that people can never blame the sucker
who does the job. For example, I would suggest that "size" be one hard
technical rule. If the patch is more than 100 lines (with context) in
size, it's not trivial any more. Really. Two big screenfuls (or four,
for people who still use the ISO-ANSI standard 80x24 vt100)

Also, I'd suggest that a _hard_ rule (ie nobody can override it) would
also be that the problem causes an oops, a hang, or a real security
problem that somebody can come up with an exploit for (ie no "there
could be a two-instruction race" crap. Only "there is a race, and
here's how you exploit it"). The exploit wouldn't need to be full code
that gets root, but an explanation of it, at least.

Andres also patches things that are plain broken, e.g. "sound doesn't work any more". By the law Linus established above, those kind of patches are forbidden to go into 2.6.x.N.

So the 2.6.x.N patches are extremely minimalistic. They are not sufficient for the average joe who wants to run a vanilla kernel. Those of us who want to run a vanilla kernel (with official patchset) and maybe some self chosen patches still need the -as patches badly! There are many people out there who are their own kernel distributors (i.e. have their own personal patchset and want to apply it to the latest stable kernel.) It does not make sense that thousands of kernel distributors are all trying to do the job Andres does now for all of them officially.

So I hope Andres will keep up with his good work.

Re:Burnout

[Anonymous Coward]

Java driver development!? I was pretty sure Java couldn't TOUCH hardware...

That's normally true, but with same native code (JNI) you could probably write bindings for a library like
libusb [sourceforge.net] (which you can use to write user-space drivers for USB devices).

The idea isn't as bad as it might sound at first. The kernel doesn't need to know about certain types of devices (eg. scanners), and keeping complexity out of kernel-space is generally a good idea.

Re:What was wrong with the old way?

[moonbender]

There's a reason Ars Technica switched from Linux to Windows, and stayed there.

Yes, there is. Quoted from their article on the redesign [arstechnica.com]:

Q. Why did you change over from Linux?

A. This is a loaded question, so we'll be brief. Ars started out on Windows NT back in 1998, but shortly after that we moved to FreeBSD, and then later, Linux. We ran Linux until March of 2004, when we made the move to Windows Servers. Linux and Apache had served us quite well, but when we turned to look at building our new CMS, .NET was simply so attractive for our needs that we felt it warranted the switch. If there are enough requests, we may do an article later documenting our thought process, but for now I'll say that the decision was largely a programming one, with the added benefit of the fact that more of us support Windows in our real lives than Linux.

I don't know - did they ever release that article documenting the thought process?

Re:Scared of 3

[Ulric]

The numbering system used by many, not all, projects is major.minor.teeny:

• Bugfixes increment the teeny number.
• New, backwards compatible features increment the minor number and set teeny to 0.
• Changes that break backwards compatibility increment the major number and set the minor and teeny numbers to 0.

And of course, the major number starts out as 0, so the only way the major number could be anything else is by introducing incompatible changes.

Libraries use similar rules, or at least rules with the same effect, except that many libraries have separate so-numbers (which dictate compatibility) and "marketing" numbers.

Re:Dunno

[tehdaemon]

"Expect major disruptions if they ever decide to revamp some kernel component like paging or smp."

If you would recall a recent interview Linus did, he said that there probably wasn't going to be anything like that in the near future, except possibly the tty stuff. Mostly just work on drivers and such. I would not be too surprised if the real reason that there is no 2.7 branch now is because there simply isn't any major system that needs a rewrite.

Re:Here's an idea...

[Sique]

That's basicly what SUN was doing with their release numbers.
Solaris 10 is in fact Solaris 2.10, and the kernel of Solaris 2.10 is the SunOS 5.10.

Solaris was released as "2", because it was the first software distribution from SUN Microsystems that was SVR4 compliant, thus making a difference to the previous SunOS releases, which were based on BSD. Solaris 2 got a rewrite of the old SunOS kernel, which was at 4.3.1 before Solaris. So the kernel was SunOS 5.0. With every new Solaris Software Release there were also minor changes to the kernel, so Solaris 2.1 had a 5.1 kernel, etc.pp. With Solaris 7 Sun got rid of the "2" (which meant Second Approach to a UNIX operating system ;) ), and while in fact the core Solaris Distribution was a release 2.7 (using SunOS Kernel 5.7), it was marketed as Solaris 7 (because in fact it was the 8th release of the Solaris 2 operating system, starting counting with 0).

Same with the Linux Kernel versions. Think of Linux Kernel 2 as the kernel series with loadable modules and SMP capabilities (different than the Kernel 1 releases, which where monolithic blocks until the Kernel 1.3 developer kernels started with loadable modules). As long as this characteristics stay stable, there is no point to go for a Linux 3 kernel. The current Linux 2 kernel is at his 4th stable feature set, and because of the numbering for feature stable releases with even numbers, it gets the fourth even number: 6 (the first three being 0, 2 and 4). The different versions of the fourth feature stable Linux Kernel 2 releases should look all the same from a userland perspective (they don't completely, but that's a rather minor side effect), so they are all called Linux 2.6. To make a difference between the single versions of the Linux 2.6 kernels you get a version numbering: the first one being 2.6.0, the current one 2.6.11.

The fourth number comes into being when it goes about differently patched versions of the stable current kernel branch. None of those four-numbered kernels is thought for a general public, they are rather experimental versions until a release candidate emerges from all those patches. And if the release candidate (maybe after some bugfixing cycles) proves to be stable enough for general use, it gets released as the next Linux Kernel Series 2, 4th stable Feature Set version (a.k.a. Linux Kernel 2.6.(n+1)).