The 2.6.20 cycle begins

It's simple, really: if some version of GlibC can use features from kernel x.y.z - it should be compatible with headers-x.y.z, if it can not - they why you are trying to compile it with headers-x.y.z ? SysCall interface is set in stone, but headers are not and one of the GlibC's tasks is to provide compatibility at the headers level for the userspace programs...

even gentoo doesn't compile anything against the kernel headers directly, they maintain a seperate package that's the headers that userspace needs extracted out of the kernel headers.

unless the kernel changes an interface that's exported to userspace (which would be a break of backwards compatability), or glibc is trying to take advantage of a new interface that's exported to userspace there is no reason to change glibc when a new kernel is installed (including no need to recompile it)

if glibc is trying to take advantage of a new interface then it's up to glibc to be able to use the right headers.

David Lang

I would say the next stable kernel release is 2.6.16.35. The phrase could also describe 2.6.18.6.

In effect, Andrew's -mm kernel is the development kernel now, with major
changes being tested in it for awhile before they hit the Linus mainline.
That was the effect of the discussions at 2004's (??) OLS (Ottawa Linux
Symposium), which made official the relationship between the Andrew and
Linus kernels that had been found to work quite well since the 2.6.0-pre
cycle at least.

Besides formalizing a working relationship that had already been found to
work quite well, the change had a number of other effects, beneficial and
not so beneficial, as well.

By the end of the 2.5 cycle, there had developed a HUGE gap between stable
and unstable kernels, and distributions were filling that gap with their
own (often incompatible with others) backports of 2.5 features to 2.4
stable. What was supposed to be the Linux kernel and therefore basically
interchangeable was ending up creating distribution lockin, as users were
finding it more and more troublesome to switch distributions due to kernel
problems, or even between distributor and
mainline-plus-independent-patches kernels. This was generating complaints
from that end, while the vendors were finding it increasingly expensive to
maintain their ever bloating patch-sets as well -- it wasn't all
deliberate vendor/distribution scheming by FAR.

The kernel devs resolved to change this in the 2.6 process and what came
of it was what we have now, a development -mm and a "stable"
Linus/mainline. Vendors/distributors are STRONGLY encouraged to submit
their patches upstream and get them integrated into mainline as soon as
possible (going thru -mm where the change will be big). Where these are
controversial or there are several solutions to the same problem, LKML
debate and/or turns in the -mm tree for evaluation hashes out the details
before they go into mainline. In any case, there's STRONG encouragement
to get a solution integrated into mainline, thus shrinking the individual
trees and keeping the individual vendor/distribution and developer trees
much closer to in-sync than they were with the traditional odd/even
developer/stable split of yore. That's one of the benefits.

It should also be mentioned that a number of kernel watchers have observed
that the kernel is maturing, and as it matures, there comes a point where
while the rate of change may remain high, the biggest changes don't tend
to be as drastic or destabilizing to the entire tree. When there are big
changes, in a mature tree with decent modularization, they will tend to be
rather more self-contained and affect the tree as a whole somewhat less.
Combine this with an arguably somewhat more sane merge strategy because
they know it's not possible to have the whole thing simply not work for a
huge segment of the base, and result is a system where improvements get
rolled out to the actual user base far faster, with (arguably) a
relatively low cost in terms of destabilization. Another benefit, of
course related to the first.

On the flip side, some have argued that the process is less stable than it
should be and indeed less stable than it was historically. While
everybody agrees stability isn't perfect, others simply point to
historical big upsets like the memory management changes early in the 2.4
stable series for support of their position that stability isn't really
worse after all. They point to the relatively large changes integrated
into the 2.6 process with rather less disruption as compared to historical
changes in stable such as that, in support for the current model. Both
sides have their valid points, of course.

Meanwhile, there have been refinements in the process as time has
progressed, giving those who want super-stable a number of options, while
preserving the general model, which seems to fit the way the current set
of kernel devs wish to work quite well.

1) It was pointed out early in the process that typically, the types of
users arguing for ultra-stability are the same corporate/enterprise types
that like to purchase support from their vendors and thus have someone to
blame when things go wrong. The enterprise distributions, particularly
Red Hat and Novell, fill this niche rather well, and provide and support
their own kernel packages. Thus, these users don't tend to use
mainline/vanilla kernels anyway, but rather their respective distribution
provided kernels, which typically lag mainline by some period. This
provides its own built-in stability buffer mechanism, and statements of
the kernel devs seem to support the idea that those wishing ultra-stable
kernels should be using vendor provided kernels, not vanilla-mainline.
The effect is that there's yet another level of stability, the various
individual developer trees (call them alpha level), the development -mm
tree (call it beta), the stable 2.6.x releases, and the ultra-stable
releases further tested and provided by various vendors.

2) That didn't prove to be enough for some, particularly as it encouraged
specific vendor dependence and a degree of lockin that some of these same
enterprise customers weren't entirely comfortable with, once again. It
also quickly became apparent that the model didn't particularly well deal
with security updates between the 2-3 month stable releases, and as
concern for security extends well beyond the enterprise community,
something else was needed.

That "something else" was the 2.6.x.y fourth field point releases,
designed to be quite conservative in the patches they accepted, and
originally designed to continue not long after the release of the next
stable regular mainline kernel.

3) The latest development has been that of the 2.6.16.x series, which now
has a maintainer (Adrian Bunk) continuing it long past the original stable
team cutoff date, as they moved forward to 2.6.17 and now 2.6.18 and .19.
As he had an interest in it and volunteered, he's maintaining continuing
2.6.16.x releases for some time, at this point basically indefinitely.

Thus, 2.6.16 has become in practice the new "stable" series, API frozen,
with only security patches and the like, with certain new drivers and the
like backported as well. Those who were formerly sticking to 2.4
primarily because they weren't comfortable with the stability (or lack
thereof) in 2.6 now have a 2.6 upgrade target.

As time goes on, it's reasonably likely another continuing 2.6.x.y will
find support. Given 4-5 third-field stable releases a year, and assuming
the rate of change continues much as it has, a continued-stable release
every couple of years or roughly one every ten third-field releases, might
be considered reasonable, provided of course trusted volunteers continue
to step up to take them. Of course, that's the future and reality may yet
change out from under that sort of prediction.

Meanwhile, the original plan was that should something really radical come
along that couldn't fit in this development model, a relatively short and
specific 2.7 may eventually come to be. There's been no real pressure for
it yet, as the current model with -mm being the development branch and
keeping things otherwise much closer integrated than was the case
traditionally, has seemed to work quite well even for larger changes.
(Again, that could be partially attributable to better modularization now
than in the past.) The possibility therefore seems pretty remote for the
time being. Still, the option is there, if it's ever found to be needed.

Of course, who knows, "life happens" as they say, and reality may intrude
on the current comfortable arrangement. If some tragedy befalls Andrew or
Linus, or they simply decide they have personal disagreements or
something, or if the DRM loophole becomes big enough to BSD Linux while
the Solaris kernel adopts GPLv3 and the FSF adopts it in place of
GNU/HURD, or... well then things will get "interesting" for awhile.
Never-the-less, the community has proven extremely resilient in the past,
the xfree86/xorg and gcc/egcs changes and SCO threat being just three
examples, we'll certainly come out even stronger for it, as with xorg, no
matter the name of what happens to be the most popular kernel in the
community.

Duncan