login
Search
With the release of the 2.6.16 Linux kernel, Adrian Bunk reiterated his previously debated intention of maintaining the 2.6.16.y kernel tree well into the future. The first 2.6.x.y release was 2.6.8.1 by Linus Torvalds [story], a quick one line fix for NFS. The idea was revisted a few months later in October of 2004 [story], but didn't actually gain momentum until March of 2005 [story] [story]. Beginning with the 2.6.11 kernel, the process was formalized with Greg KH and Chris Wright officially maintaining 2.6.x.y releases [story] until 2.6.(x+2) is released. For example, stable patches will be applied to the current 2.6.16.y kernel by Greg and Chris until 2.6.18 is released sometime well in the future.
Adrian's plan is to pick up the development of the 2.6.16.y kernel at that point, maintaining it much as the 2.4 kernel tree is is maintained [interview]. His intention is to maintain the tree as long is it is used and people contribute patches. The earlier debate on this idea was met with mixed reactions. At that time Greg KH cautioned, "the time and energy to do this for a long period of time is huge. If I were you, I would listen to the people who have and do maintain these kinds of kernels, it's not a simple job by any means."
From: Adrian Bunk [email blocked] To: Linus Torvalds [email blocked] Subject: 2.6.16.x will be a long-living kernel series Date: Mon, 20 Mar 2006 13:02:29 +0100 As proposed some time ago [1], I'll continue the 2.6.16.x series after 2.6.17 will be released. A short FAQ is below. cu Adrian [1] http://lkml.org/lkml/2005/12/3/55 Q: What will be the rules for patch inclusion in the 2.6.16.x series? A: There will be more relaxed rules similar to the rules in kernel 2.4 after the release of kernel 2.6.0 (e.g. driver updates will be allowed). Q: Why not start with the more relaxed rules before the release of 2.6.17? A: After 2.6.16.y following the usual stable rules, the kernel should be relatively stable and well-tested giving the best possible basis for a long-living series. Q: How long will this 2.6.16 series be maintained? A: That depends on how long people use it and contribute patches. Q: Stable API/ABI for external modules? A: No.
From: Arjan van de Ven [email blocked] Subject: Re: 2.6.16.x will be a long-living kernel series Date: Mon, 20 Mar 2006 13:05:22 +0100 On Mon, 2006-03-20 at 13:02 +0100, Adrian Bunk wrote: > As proposed some time ago [1], I'll continue the 2.6.16.x series after > 2.6.17 will be released. ehh are you doing this as part of the regular stable effort ? Or in parallel to that?
From: Adrian Bunk [email blocked] Subject: Re: 2.6.16.x will be a long-living kernel series Date: Mon, 20 Mar 2006 13:12:07 +0100 On Mon, Mar 20, 2006 at 01:05:22PM +0100, Arjan van de Ven wrote: > On Mon, 2006-03-20 at 13:02 +0100, Adrian Bunk wrote: > > As proposed some time ago [1], I'll continue the 2.6.16.x series after > > 2.6.17 will be released. > > > ehh are you doing this as part of the regular stable effort ? Or in > parallel to that? This seems to be the point I never manage to communicate correctly... After 2.6.17 will be released, there will be the last regular 2.6.16.x kernel by Greg and Chris. I'll continue the 2.6.16.x series _after_ this last regular stable kernel. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Renumbering.
Renumbering by Linus have made so much noise.
And in result we have the same old numbered just shifted by 1 octet to right ;-)
I have impression that would be pretty okay have Linus opted to inc second number from left more often: not 2.6.11.1 but 2.8.1 or something like that.
As version number conserned, there is room for whoppy (1<<sizeof(char)*8) versions so we could probably have lived Okay with stable version 2.144.7 while Linus went off to 2.145.x development. Current most minor version number (third one) changes once per 2-3 months - 10-12 numbers per year - with one byte for minor version that would be about 20 years...
Huh?
Who says the numbers between the decimals are octets? Nothing stops there from being a 2.6.eleventybillion, other than the time it takes to get to such a version number.
linux/version.h
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
Only one byte for each part...
Yeah, so?
Like major and minor numbers in device inodes, the bit allocation can change. It's not like it's embodied in an RFC somewhere. Nothing stops this from being:
Granted, you don't get to "eleventybillion" that way on a 32-bit machine, but you get the idea.
There's still some code that tests LINUX_VERSION_CODE against a bare 0x020101 or whatever. That code still works even with the above macro. (I'll let you muse on why that's true.)
Except that each new release
Except that each new release is packed with new features and changes. Which introduces new bugs which are -sometimes- very noticable and make it a very BIG deal to upgrade servers.
well, like it or not (i don't
well, like it or not (i don't !) that's the way it's supposed to be. We are supposed to only trust distribution released kernels.
F.
That is only a recent thing
Having ot Trust distro kernels is a relatively recent development. This used to not be true and that was one of the cuases of the uproar over the numbering change.
If you run Debian, I don't th
If you run Debian, I don't think the debian kernels add a lot of stability fixes. So you basically run a very old kernel.org kernel with _some_ security fixes (the ones which get an advisory).
Nobody is supposed to use only distro kernels, if you are prepared to track patches and fixes yourself you can use whatever you want. But if this works out, I will certainly use it for server and I think a lot of other people will do this as well. For my desktop/laptop I'll use the latest and greatest.
Distro-patched kernels
And what was one of Slack's selling points ... ?
Yes, iirc it was that it always used vanilla, unpatched kernels!
So by all means say "only use distro-patched kernels". But that's not much help when the distro kernel hasn't been patched.
Cheers,
Wol
Typo: Linux Torvalds (n/t)
.