Device drivers can make or break an operating system. The best engineered kernel is useless if applications running on it cannot interface with the outside world or if device manufacturers cannot readily support it with their wares.
When it comes to device drivers, Linux is at once a success story and an on-going drama. On one hand, the OS is the darling of silicon suppliers, peripheral manufacturers, or independent hardware vendors. Because Linux source code is by definition available to all, hardware makers use Linux to prototype and debug new products. Developers working on other platforms – especially embedded OSes – often look to Linux-based code in creating their own drivers.
On the other hand, much of the code developed for initial hardware support never makes it out of the lab or gets stuck in one-off, proof-of-concept kernels. Hardware manufacturers often don't have the wherewithal to submit their drivers upstream to maintainers of the Linux kernel tree, or they treat driver source code as closely-held intellectual property. Linux support is often shelved after initial development in favor of support for higher volume Windows versions of comparable functionality.
For years, the Linux community, and industry segments that depend on and commercialize Linux, have collectively wrung their hands over the need for more and better drivers for Linux. At the Linux Foundation 2007 Desktop Linux Survey, 44% percent of respondents indicated that missing driver support was the primary barrier to migration to Linux, and sixty-three percent urged Linux desktop developers to focus their efforts in 2008 on open source drivers for proprietary hardware.
In fairness to all parties involved, fostering more ubiquitous hardware support faces a series of both technical and structural challenges.
Evolution of driver APIs in the Linux kernel
Over the lifetime of the GNU/Linux OS, the kernel development community has taken pains to maintain consistency in system calls, just as the GNU project and others have done for application libraries. However, kernel developers felt at liberty to experiment with new kernel internals and driver application programming interfaces (APIs).
Driver APIs evolved in both small and large steps. For example, when the 2.6 kernel debuted in early 2004, it took over a year for the new kernel and drivers to propagate across server, desktop and embedded applications. Novell/SUSE and Red Hat were quick to productize prototypes from the 2.5 kernel, but quality support for notebooks and the peripherals in many intelligent devices lagged, due to Windows-specificity of notebooks and to the conservatism and undercapitalization of embedded Linux suppliers.
Source vs. binary
For IT professionals coming to Linux from other platforms, it is important to understand the relationship between kernel versions and device drivers. While commercial and most end-user Linux distributions provide binary OS images, replete with pre-built kernels, drivers, utilities, and applications, it is all still open source code. Implicit in the Linux kernel architecture and build model is the idea that device drivers are built, from source, specifically for a given kernel version.
Ideally, drivers end up in the Linux source tree, get built and configured, finally ending up included with the kernel boot image. Build-wise, drivers can also be packaged as kernel modules loaded after booting the system. Module writers are still expected to supply source code to enable building the driver with header files that match the state and APIs of the kernel build.
And therein lies the rub: independent hardware vendors, or IHVs, are accustomed to providing drivers in binary form for Windows, Solaris and other systems; they are not ready and willing to offer comparable drivers in source just for Linux.
The alternative has been to supply driver modules in binary form only. Practical, but also fraught with challenges, binary modules are by definition version and build specific and may not match the kernel in your distribution. The kernel community hates binary modules because they are difficult to debug – no source code – and bridles at the thought of parasitic proprietary code entering the open source garden. Some go as far as to label binary modules as "illegal", but it remains an open question as to whether binary modules violate the GPLv2 license (General Public License version 2) that governs the kernel or copyrights.
Open source, or any other kind of sharing, is still new to most of the IT universe. Justifiably or not, corporate lawyers at IHVs and elsewhere are averse to expose intellectual property in the form of source code. Stated reasons from patent and intellectual property (IP) lawyers tend to focus on critical IP (for example, sub-licensed code, trade secrets in algorithms, register definitions) embodied in device driver sources. Unstated reasons can include poor code quality, informally acquired code and uncertainty arising from lax source control. With chip vendors, this reticence extends beyond source code to even basic device specifications, available only under non-disclosure agreements (NDAs).
Breaking the driver log jam
The situation is by no means irresolvable. A range of initiatives and projects to remedy Linux driver issues have been put out by many Linux-interested parties:
- Kernel development
Linux kernel developers address the need for more drivers in several ways. First and foremost, the willingness of 2.6 maintainer Andrew Morton and most subsystem maintainers to integrate contributed drivers into the main kernel tree has resulted in shared maintenance and community testing worldwide. Also important have been investments by companies and individual developers in fortifying subsystems to support ubiquitous chipsets and technologies like USB and WiFi, as well as interfaces that target enterprise heavy iron.
- Linux drivers project
The Linux Drivers Project comprises over two hundred Linux kernel developers and project managers banded together to develop and maintain drivers for Linux. They work together with silicon suppliers and IHVs, specifying, developing, integrating and maintaining drivers in the main kernel source tree. Their current work includes drivers for I2C (Inter-IC bus), IR (infrared), TTY (teletype-style terminal) over TCP/IP, high-speed data capture, specific USB drivers, and others.
- Disclosure by proxy
Many chipset manufacturers require an NDA from anyone wishing to study specifications for new devices, before and after a product launch. In many cases, individual and corporate developers are reluctant or unable to execute these NDAs, impeding driver development. To overcome this particular bottleneck, < a target="_blank" href= "http://www.linux-foundation.org/en/NDA_program>the Linux Foundation NDA Program launched in 2006 to facilitate disclosure of proprietary specifications to community developers. The program mediates between developers and NDA-toting suppliers, reviewing NDAs and negotiating changes to NDAs to accommodate open source development. The program also offers indirect signing, wherein the Linux Foundation executes the agreement on behalf of developers and holds the specifications in question in escrow; developers receive the information they need and the Linux Foundation acts as guarantor against unintended disclosure.
- Distro suppliers
Enterprise Linux distribution suppliers like Red Hat and Novell, and embedded platform providers like MontaVista and Wind River, do their part to expand device support and driver mainstreaming as part of their daily business. They work closely with hardware suppliers to ensure that each new commercial release – Red Hat Enterprise Linux, Novell Desktop, etc. – and non-commercial edition – Fedora Core, OpenSUSE, etc. – come with rich and useful complements of device drivers. These and other companies fund internal teams focused on driver development, and also donate resources to projects like the Linux Driver Project, lead by Novell's Greg Kroah-Hartman.
IT managers need to consider drivers when considering migration to Linux. Device support is an area too-frequently overlooked and can trip up migration late in the project life cycle. The good news is that multiple routes exist to confirm that your company's complement of devices will work with a particular distribution or version of Linux: you can work with branded commercial suppliers to validate support for, develop as needed and perform integration of drivers on actual hardware; you can leverage the services of large community of consultants and independent integrators for the same purposes; and, of course, since Linux is open source, you can always do it yourself.
About the author: Bill Weinberg is an independent analyst for Linuxpundit.com and serves in a part-time executive capacity for Linux Phone Standards Forum (LiPS). Previously, at Open Source Development Labs (OSDL) he served as senior technology analyst and also managed the OSDL Mobile Linux and Carrier Grade Linux initiatives. Prior to OSDL, Weinberg was a founding member of MontaVista Software, helping to pioneer and ultimately to establish Linux as the leading platform for intelligent devices.