KS2008: Linux 3.0

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 them.

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 either.

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 other interfaces.

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.