The Linux kernel
summit is happening this month, so various discussion topics are being
tossed around on the Ksummit-2008-discuss
mailing list. Alan Cox suggested
a Linux release that would "throw out" some accumulated, unmaintained cruft
as a topic to be discussed.
Cox would like to see
that release be well publicized, with a new release number, so that the
intention of the release would be clear. While there will be disagreements
about which drivers and subsystems can be removed, participants in
the thread seem favorably disposed to the idea—at
least enough that it should be discussed.
There is already a process in place for deprecating and eventually removing
parts of the kernel that need it, but it is somewhat haphazardly used. Cox
At some point soon we add all the old legacy ISA drivers (barring the odd
ones that turn up in embedded chipsets on LPC bus) into the
feature-removal list and declare an 'ISA death' flag day which we brand
2.8 or 3.0 or something so everyone knows that we are having a single
clean 'throw out' of old junk.
It would also be a chance to throw out a whole pile of other "legacy"
things like ipt_tos, bzImage symlinks, ancient SCTP options, ancient
lmsensor support, V4L1 only driver stuff etc.
Cox's list sparked immediate protest about some of the items on it, but the
general idea was well received. There are certainly sizable portions of
especially for older hardware, that are unmaintained and probably completely
broken. No one seems to have any interest in carrying that stuff forward,
but, without a concerted effort to identify and remove crufty code, it is
likely to remain. Cox has suggested one way to make that happen;
discussion at the kernel summit might refine his idea or come up with
something entirely different.
Part of the reason that unmaintained code tends to hang around is that the
kernel hackers have gotten much better at fixing all affected code when
they make an API change. While that is definitely a change for the better,
have the effect of sometimes hiding code that might be ready to be removed. In
earlier times, dead code would have become unbuildable after an API change
or two leading to either a
maintainer stepping up or the code being removed.
The need to make a "major" kernel release, with a corresponding change to
the major or minor release number is the biggest question that the kernel
hackers seem to have. Greg Kroah-Hartman asks:
Can't we do all of the above today in our current model? Or is it just
a marketing thing to bump to 3.0? If so, should we just pick a release
and say, "here, 2.6.31 is the last 2.6 kernel and for the next 3 months
we are just going to rip things out and create 3.0"?
There is an element of "marketing" to Cox's proposal. Publicizing a major
release, along with the intention to get rid of "legacy" code, will allow
interested parties to step up to maintain pieces that they do not want to
see removed. As Cox, puts
I thought it might be useful to actually draw some definite lines so we
can actually get around to throwing stuff out rather than letting it rot
forever and also if its well telegraphed both give people a chance to fix
where the line goes and - yes - as a marketing thing as much as anything
else to define the line in a way that non-techies, press etc get.
Plus it appeals to my sense of the open source way of doing things
differently - a major release about getting rid of old junk not about
adding more new wackiness people don't need 8)
Arjan van de Ven thinks
that gathering the list of things to be removed is a good exercise:
I like the idea of at least discussing this, and for a bunch of people
making a long
list of what would go.
Based on that whole list it becomes a value discussion/decision; is there
this to make it worth doing.
Once the list
has been gathered and discussed, van de Ven notes,
it may well be that it can be done under
the current development model, without a major release. "But let's at
least do the exercise. It's worth validating the model we have
once in a while ;)"
This may not be the only discussion of kernel version numbers that takes
place at the summit. Back in July, Linus Torvalds mentioned a bikeshed painting project that he
planned to bring up. It seems that Torvalds is less than completely happy
with how large the minor release number of the kernel is; he would like to
see numbers that have more meaning, possibly date-based:
The only thing I do know is that I agree that "big meaningless numbers"
are bad. "26" is already pretty big. As you point out, the 2.4.x series
has much bigger numbers yet.
And yes, something like "2008" is obviously numerically bigger, but has a
direct meaning and as such is possibly better than something arbitrary and
non-descriptive like "26".
Version numbers are not important, per se, but having a consistent,
well-understood numbering scheme certainly is. The current system has been
in place for four years or so without much need to modify it. That may
still be the case, but with ideas about altering it coming from multiple
directions, there could be changes afoot as well.
the kernel hackers themselves, there is little benefit—except,
perhaps, preventing the annoyance of ever-increasing numbers—but version
numbering does provide a mechanism to communicate with the "outside
world". Users have come to expect the occasional major release, with some
sizable and visible chunk of changes, but the current incremental kernel
releases do not provide that numerically; instead, big changes come
with nearly every kernel release. There may be value in raising the
visibility of one particular release, either as a means to clean up the
kernel or to move to a different versioning scheme—perhaps both at once.
to post comments)