Kernel Comment: Get testing!

by Thorsten Leemhuis

Linux users should test the latest kernel from time to time – if they don't, they shouldn't be surprised if something important gets broken the next time a major update is released.

New drivers for old kernel versions – it's a common request, especially from people new to Linux, and the Linux Kernel Backporting Project wants to make it happen. It's a great idea, as it can sometimes be injudicious or impossible to swap a tried and tested kernel for a newer kernel and, until now, it's been hard to get hold of new drivers any other way.

Hopefully users and distributors will only use this new option where they have to. Even now, there are too few users testing the very latest versions of the Linux kernel; the loss is, however, their own, as we can see from the following hypothetical example, based on a problem which cropped up in the c't laboratory:

In May 2010, a user bought a new PC and installed Ubuntu 10.04 LTS (Linux kernel 2.6.32). It ran without a hitch for two years. As he planned to continue to use the system for a few years still and was keen to have the latest applications, this summer he updated his system to Ubuntu 12.04 LTS (Linux kernel 3.2). Having updated, however, he was disappointed to find that the new version wouldn't boot. The reason: the manufacturer had implemented a third monitor output on the built-in graphics card using an elaborate wiring scheme not found on any other graphics card of this type; no-one had noticed that a change merged into Linux 2.6.34 did not work with this scheme, as the graphics card in question was not in widespread use.

If that user had tried out a new kernel from time to time or had used a Live CD to check out Ubuntu 10.10, the problem might have been tackled in good time. Now, however, fixing it is going to be difficult – two years have passed between the change which caused the problem being merged and the bug report, with thousands of other changes having been merged since; furthermore, the graphics card in question is now old, and problems concerning more recent, more widely used hardware will inevitably be higher on developers' to-do lists.

Feedback from readers to The H and its sister publications in Germany demonstrates that problems such as this occur over and over. They even arise under Windows, though here they are far rarer, since, as well as beta testing, hardware manufacturers and makers of proprietary software deploy legions of paid testers and quality assurance engineers to catch these types of problems.

By contrast, paid testers in the open source arena are, to say the least, scarce – even major performance losses sometimes take an eternity to be picked up on, since hardly anyone carries out systematic testing on the kernel. It's also worth noting that, given the sheer volume of computer components available and the diversity of ways in which they can be combined, finding performance problems is a lot simpler than hardware compatibility testing. It therefore follows that the only way of finding bugs is field testing – and not just of drivers, but also encompassing schedulers, file system code and the hundreds of other functions taken care of by the kernel. And slowing the pace of ongoing development is not a solution.

So if you overdo the motto, "Never touch a running system" and hang doggedly onto an old distribution or kernel, you shouldn't be too surprised if a function that matters only to you and a handful of other people stops working after a major update. You would be well advised to try out a new kernel or a pre-release version of a Linux distribution from time to time. If you find some bugs and help the developers resolve them, you're helping yourself, as well as helping to make Linux better. It's a nice, satisfying way of doing your bit for the public good and of saying "thank you" for the work that other people put into Linux.