Built to Last

The speed of the development process is impressive; the nearly-released 2.6.33 kernel is the product of nearly 11,000 individual changes affecting nearly a million lines of code (look here for more 2.6.33 statistics). Those numbers are boringly normal for a three-month development cycle; things are always moving that fast.

Given that, one might think that, by now, very little of that 2.6.12-rc2 kernel which was first committed to git would remain. After all, over 500,000 lines were deleted in this development cycle alone. I got curious, and decided to look a bit deeper. The result was the creation of some brutally hackish Python scripts, the expenditure of about a week of solid CPU time, and some statistics on the age of the kernel code base.

It turns out that, of the approximately 12 million lines of code and documentation that make up the 2.6.33 kernel, about 31% dates back to that 2.6.12-rc2 commit. A third of our current kernel has not been touched in the last five years.

Some parts of the kernel (including the network stack, the filesystem layer, and, alas, the documentation directory) have higher-than-average amounts of old code. Over 40% of our documentation is at least five years old. Some of that documentation covers things which haven’t changed – how to configure old hardware, for example, and Klingon language support – but much of the rest is just … old.

The newest code can generally be found in the core kernel, which is much more aggressively improved and updated. But, even there, 25% of the memory management layer dates from 2.6.12, as does about 13% of the “kernel” directory.

Does this mean that we have a lot of old and unmaintained code sitting around? In places, that will certainly be true; no body of code this large can be without the occasional cobweb-filled corner. But I also think these numbers show that we have built this kernel to last. The development community’s focus on code quality and maintainability means that, even in a rapidly-changing kernel with contributions from thousands of developers, a third of our code works so well that it has not even needed a dusting-off in the last five years.