Linux has become far more friendly in recent years, but one thing that hasn't gotten any easier over time is tracking down third-party device drivers for hardware that isn't supported with the standard kernel drivers shipped by a distribution – that's where tools such as Jockey, and the idea of automated driver updates can really come in handy as a stop-gap solution.

The Problem with Drivers

Many users have experienced the frustration of purchasing a hardware device – or an entirely new computer – only to find that a particular hardware component is not supported by their Linux distribution. Support issues often occur with video cards (which occasionally require proprietary drivers to operate with Linux), web cams, and similar devices, but this experience sometimes applies to other components too. When hardware works, the experience is great: auto-detection, auto-configuration, the works. But when it doesn't, too often, the user experience is left wanting. In such situations, you can count yourself lucky to receive even a useful message saying "this hardware is unsupported by your Linux distribution; please contact your software or hardware vendor."

In reality, drivers are often available for some of this seemingly "unsupported" hardware – both open source, and some not open source – but these drivers haven't made it into the distribution yet and are not yet in the official Linux kernel. (Drivers that aren't in the kernel typically aren't included with the distribution unless the vendor takes some extraordinary measures.)

This lack of delivery infuriates users, especially when Google tells them that there are drivers available. The situation is compounded in the case of "enterprise" Linux distributions that are updated relatively infrequently, although even distributions receiving overhauls every six months can be left out by hardware coming to market in-between.

Many distribution developers listen sympathetically to such frustrations, but their response is often to recommend waiting for the next distribution update. They take the ideological position that it's better to provide fully functional drivers that have had many months of testing throughout the Linux community than to ship something not yet in the official kernel, and perhaps not quite ready for prime time. The assumption is that users will be happy to wait for the polished end product, and that users who really do need drivers now will happily follow a series of arcane commands to build those drivers just as a distribution developer would do.

This assumption is where reality differs from optimism. The suggestion that users go out and build the drivers for themselves is likely a lost cause. Users who understand how to build drivers face little in the way of hurdles, but the rest of the user population, who are not familiar or interested in development tools, will deem this Linux distribution a "failure" and move on to something that works for them. When the drivers are available at the time of the next release, those users who were unable to use the distro previously are unlikely to return, fearing a similar experience.

Driver Update Solutions

Many users would rather have some hardware support now than the promise of great support in six months, especially with the pace of new hardware becoming obsolete as it waits on the shelf. In the past, many brave users have turned to websites offering advice about building and installing drivers from third-party sources – after making sure all of the necessary build tools and kernel sources are installed – only to find themselves in a never-ending cycle of recompiling those same driver updates every time they perform a system update.

Linux is reaching a new audience – especially on the desktop – where there are no sys admins to build and install device drivers. Developers have attempted to implement various solutions to provide users with stop-gap driver updates before their distribution contains full support. They exploit modular capabilities of the Linux kernel, which can load compatible device driver modules not shipped along with the distribution, and build pre-compiled kernel modules that serve as a drop-in replacements for missing drivers when a distribution is installed or updated. Several distributions have embraced these efforts, while others merely tolerate their separate existence.

Linux vendors are currently pursuing a number of solutions to the driver problem. Fedora is at work on several parallel efforts to build what are known by various names as "kmods" (short for "kernel module"), kmdls, and similar. These special packages are hosted in separate repositories maintained by developers closely associated with the distribution itself (although the drivers themselves are not a part of the Fedora distribution proper).

One of the major problems with deploying these pre-built driver updates is that they must closely match the Linux kernel running on the target system and be updated whenever the kernel is updated or the system won't load the drivers when it is rebooted.

Ubuntu ships a software tool known as Jockey as part of the distribution. (Jockey was formerly called "Restricted Driver Manager," because of its ancient heritage as a manager solely of proprietary drivers, but it has long since come to more common usage.) Jockey doesn't obtain driver packages, but rather manages previously installed driver packages, giving the user the opportunity to install third-party drivers if they would like to do so.

When started, Jockey will scan the system to determine what hardware devices are installed and which drivers are currently loaded. Then it presents the user with a graphical menu of any alternatives (Figure 1). If a user wishes to install a third-party or proprietary driver, Jockey will handle the configuration.

Figure 1: Jockey provides driver information for Ubuntu's Hardware Drivers window.

Linux distributions aren't the only forces supporting the installation and management of third-party drivers. Tools such as DKMS (Dynamic Kernel Module Support), originally written by various people at Dell, support automatically rebuilding drivers from source code whenever the system changes substantially, for example, upon kernel upgrade. This brute force approach does rely upon the user having certain tools installed on their system (usually trivially available as part of a basic or developer installation package set) but is nominally transparent otherwise in daily operation. So long as the source code remains compatible with the state of kernel, the driver or drivers will be installed and available to use.

Enterprise distributions get more of a break when it comes to deploying driver updates because they often come with a "guarantee" not to break binary compatibility between the kernel and installed driver updates without some kind of prior notice. Retaining this binary compatibility doesn't come for free, and there are down sides – chiefly that the kernel is often out of date compared with the faster moving upstream distribution kernels – but enterprise vendors place a premium on retaining binary compatibility as part of their value-add proposition. From the user's point of view, it does simplify driver updates: a "kmod" built for Red Hat Enterprise Linux 5 or SUSE Linux Enterprise Server must only be built once and will continue to function across most updates.

Users have the choice of obtaining a fast moving, free distribution and taking their chances with drivers or paying for an enterprise Linux distribution and hoping to get a driver package from their vendor. But there is a third option – automating the process of installing and managing third-party drivers in both types of distribution.

Automating Driver Updates

Having an ability to ship updated Linux kernel drivers – for however brief a time before a distribution has built-in support – certainly sits well with many users. Whether the technology builds drivers from source or uses pre-built driver packages doesn't really matter too much to the user once they have located and installed those driver updates.

But what if users didn't have to go to the trouble of locating updated drivers? What if a system could automatically locate and install driver updates on their behalf?

The holy grail of driver updates for Linux distributions would be a completely automated system for determining hardware compatibility, locating the most appropriate driver update, and installing it transparently (or possibly with only a simple option for approving the update). Efforts are underway to reach this goal soon. One piece of the puzzle – managing the installation of optional device drivers – has been addressed by Ubuntu developers in the form of ongoing work on Jockey.

Another group is working on solving problems around automatically locating third-party sources of device drivers through an online database. The effort, which is still in its early stages, is happening within a workgroup hosted by the Linux Foundation. This workgroup is working on an online database service known as drivertool that can be used to discover the most appropriate driver for a particular target system. The goal of the database service is to provide a list of repositories containing driver packages that are compatible with the target system. An XML-RPC protocol has been defined through which Jockey can send such system information anonymously and manage the subsequent installation of third-party driver packages suggested by the database.