Prior to this year's kernel summit, Alan Cox had
topic: devote a development cycle to the removal of old, unused features -
possibly breaking compatibility in places - and release the result as
Linux 3.0. Alan did not attend the summit itself (the fact that it is
being held in the U.S. was enough to ensure that), but his suggested topic
was the first order of business. The result: it looks like there is no Linux 3.0
forthcoming right away, and the removal of older features is not on the
There was some talk about the cost of maintaining older drivers and
interfaces which are used by few people. This code requires updates for
API changes and may contain security holes. In many cases, the drivers are
for hardware which is unable to support features needed by contemporary
software, with the result that users complain about tools like PulseAudio
not working properly.
Linus came into the discussion early to state his unhappiness with the
idea. The cost of maintaining these old drivers, he asserts, is
essentially zero. And, in places where there are costs, that is OK with
him as well. In particular, it's fine with Linus if API changes are a
pain; he wants developers to have to think about whether an API change is
worth the trouble or not.
Linus also pointed out that a lot of hardware which kernel developers see
as being useless junk is, in fact, still useful in many parts of the
world. There are a lot of people using old stuff, and he does not want to
pull the rug out from under them. He is also not concerned about claims of
possible security problems with the older code; should such problems exist,
he says, they will affect so few people that it's really not worth the
trouble for any self-respecting cracker to exploit. So, he concluded, any
sort of driver removal might end up getting rid of all of five drivers,
which is probably not worth the effort.
James Bottomley expressed concern that, by disclaiming concern about things
like security issues, we could be creating a two-tier system of support.
Older hardware may be nominally supported, but no developers are really
interested in keeping the code up, and nobody has the hardware to test
Christoph Hellwig pointed out that creating a major release which only
removed features would be a "marketing disaster."
From there, the discussion began to drift a bit. Dave Jones suggested (to
general applause) that
a useful thing to deprecate would be the "deprecated" marker used within
the kernel source. Deprecated functions generate large numbers of
warnings, but nobody bothers to fix them; all the deprecation warnings
really do is mask other, more important warnings. Christoph noted that the
checkpatch.pl script can also warn about deprecated functions, and that it
was a much better place for it: there, the warnings affect the person
submitting a patch instead of everybody building a kernel.
Then it was suggested that, perhaps, a concerted effort should be made
toward the removal of all warnings from the kernel build. That idea did
not get very far either. Quite a few warnings from GCC are bogus, in that
they are complaining about entirely valid code. Fixing warnings like that
risks masking other problems and introducing bugs in its own right.
Christoph suggested that the warning issue could only really be resolved
when we start shipping GCC with the kernel source.
The sparse tool was discussed for a bit; the warnings generated by sparse
are seen as being more useful much of the time. But, as Linus noted,
sparse has its own set of bogus diagnostics and is not a perfect solution
Heading back toward the original topic, the developers talked about the
maintenance of ancient system call compatibility interfaces. Linus talked
about how nice it is to know that we can still run binaries from 1991; we
should be proud of that fact. The associated cost is, once again, quite
small. Matt Mackall then said that, if we are continuing to maintain those
interfaces forever, there is little point in discussing the removal of
The end result from this discussion would appear to be that there will be
no change. Compatibility with old hardware and interfaces remains a
priority for the kernel, especially as long as the cost of retaining that
compatibility is small.
to post comments)