By Jon Masters
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.
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.
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.
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.
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.
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. |