New directions in Linux driver management

Conclusion

We have a long way to go before you can insert a new device and have reliable driver discovery, but we'll likely get there in the end. Many people are enthusiastic about the recent developments in driver support. Others worry that these efforts will make it easier for proprietary drivers, or that developers won't have a motivation to get their third-party drivers into the official Linux kernel.

To a certain extent, it is true that such processes will make life easier for those who don't want to play by the established rules of the Linux community, but then, there's no guarantee that they were interested in playing by the rules in the first place. All these efforts offer a means to eliminate binary drivers without placing the onus on the end user.

Compatibility

You might wonder why obtaining and installing drivers is so difficult on Linux, when on Windows and Mac systems it is simply a matter of dropping in a single driver file. The difference is that both Microsoft and Apple have driver development "models," complete with standardized APIs, that allow a developer to write the driver using a kernel interface that will not change. Microsoft calls this the "Windows Driver Model" (WDM). If you have ever used a Microsoft Windows system, you have perhaps seen drivers listed in the Windows Device Manager as being "WDM." There is no equivalent "Linux Driver Model."

Driver development models and APIs are a double-edged sword. On the one hand, they can be great for users who need to install drivers from third-party sources without worrying about their compatibility. Microsoft even has a driver signing program that allows developers to submit their drivers for official certification by Microsoft. Signed drivers will install without any kind of warning and be trusted by Windows to play by the rules. But in return for this driver interface, Microsoft is tied into supporting a "stable" kernel API for a number of years, which in reality means almost indefinitely. Because the API cannot change, Microsoft's Windows kernel developers are limited by what pieces of the kernel they can change and by how much.

Microsoft is forced to make such trade-offs because they work under a proprietary software development model in which source code is not available. But because Linux is open source, and the barrier to entry for getting code into the kernel is reasonable, Linux kernel developers have taken the view that supporting an official "Linux Driver Model" would artificially limit the ability for the kernel to evolve over time. For this reason, compatibility is not, in general, guaranteed between one Linux kernel and the next – even a relatively small change might completely alter the interface used by an installed device driver.

The Linux kernel community has taken remedial steps to make life easier for driver developers to get their drivers into the official kernel. Greg Kroah-Hartman (known within the community as "Greg K-H") created a Linux Drivers Project several years ago to facilitate giving free programming resources to those want to create Linux drivers. In recent times, Greg has also created a special part of the Linux kernel sources where unfinished drivers can live. If distributions want to make these drivers available to users, they need only flip a configuration option. It's not a perfect situation, but it should help to encourage more third-party developers to get their code into the official kernel.

Some finished drivers do not make it into the official kernel for one reason or another. Often, these are proprietary kernel drivers (drivers for which the source is not fully available) that are only available from a particular hardware vendor. But it is not just proprietary drivers that don't make it into the kernel. Some developers aren't ready to submit to the rigorous process of submitting their code to the official kernel.

The Author

Jon Masters is a Linux kernel engineer working for Red Hat, where he is responsible for maintaining the Red Hat Enterprise Linux kernel ABI and module support. He has authored a number of books and hundreds of articles on Linux programming, the Linux kernel, and embedded Linux devices. He began his first college degree in Computer Science at the age of 13 and recently began a daily podcast that summarizes the activities of the Linux kernel development community.

Buy Linux Magazine

Related content

AMD has put its money where its mouth is, and published the first free Linux drivers for its ATI R500 and R600 graphics cards in collaboration with Novell. After a lengthy break, Nvidia has also released a new version of its proprietary graphics driver.

Version 2.0.17.4 DKMS (Dynamic Kernel Module Support), a framework that facilitates the installation of Linux drivers, has just been released. Besides bugfixes the new release includes a method for creating Debian driver packages.

Kernel developer and Novell coworker Greg Kroah-Hartman manages new drivers in a separate tree for the Linux drivers project. He most recently reported that a few projects will have to depart from Kernel 2.6.33, among them also Google.

Andy Ritger, NVIDIA manager responsible for the Linux graphics cards, as announced on the X.org mailing list that the graphics chip company will no longer develop the open source 2D video drivers for its chips. He recommends using the VESA X driver instead.