Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Linux Device Drivers Update

by Derrick Story and Allen Noren
06/08/2001

Anyone who has ever tried to plug a peripheral into a Linux box knows the importance of device drivers. This is an exciting area of Linux development, and we thought it was time to sit down with O'Reilly book author, Jonathan Corbet, to talk about device drivers now and what we might expect in the future.

In addition to co-authoring O'Reilly's Linux Device Drivers, 2nd Edition with Alessandro Rubini, Jonathan is the executive editor for LWN.net. He first started playing around with the Unix source back in the early 1980s, when a gullible instructor at the University of Colorado let him "fix" the early BSD paging algorithm. He's been working with systems programming ever since, and first started playing with Linux in 1993. By 1997, it was clear that Linux was going somewhere, so he co-founded a consulting company, and an electronic newsletter to publicize it. The rest, as they say, is history.

In this interview, Jonathan discusses the changes in the device driver world since version 2.0, takes an educated guess or two at what's coming down the pike, and provides a few insights into the actual development process for these very important tools.

Story: The second edition of Linux Device Drivers covers version 2.4. What are some of the notable changes since version 2.0?

Corbet: Perhaps the biggest change, one that will affect every driver author, is the incorporation of fine-grained locking in the kernel. In 2.0, everything was protected by the "big kernel lock," and device drivers had no need to deal with concurrency on SMP systems. Version 2.2 had split that up somewhat, but it's only in 2.4 that locking has, in many cases, been pushed down into the driver level itself. Any device driver that is not written with SMP in mind is not correct in 2.4.

Related Reading:

Linux Device Drivers

Linux Device Drivers, 2nd Edition
By Alessandro Rubini & Jonathan Corbet
2nd Edition July 2001
0-59600-008-1, Order Number: 0081
560 pages (est.), $39.95 (est.)

Beyond that, there have been numerous changes to many kernel subsystems. Bottom halves have been replaced with tasklets, the scheduler queue has been replaced with a new event-scheduling mechanism, and the block and network driver interfaces have been substantially changed. The number of platforms supported has increased significantly, as has the number of devices. Many things have been cleaned up; the 2.4 driver interface is much nicer to work with than earlier versions.

Story: Those are substantial changes. That leads me to wonder then, what's coming down the pike? Version 2.5 is about to be released.

Corbet: Trying to predict what will happen in 2.5 is sort of like trying to predict next year's weather. You may know what the general climate will be, but the details are guaranteed to be surprising. Some of what the kernel hackers have in mind can be seen in my kernel summit write-up.

Some of the things that seem possible, and which affect device drivers, include:

Story: Tell us about portability issues from one platform to another.

Corbet: The kernel code does a very nice job of hiding most of those issues most of the time. All that is really needed is that a driver writer follows a set of rules, and the chances of writing a portable driver are pretty good. These rules include: make no assumptions about byte ordering, do not directly de-reference pointers into I/O memory, use the provided interfaces for operations like DMA, etc.

Story: Well now that we're talking about this, are there any portability issues going from one version of Linux to another? If so, what are they and how do we handle them?

Corbet: Absolutely. Portability across Linux kernel versions can be harder than portability across hardware platforms.

The kernel developers feel no need to keep the internal kernel API constant, especially during a development series. API changes are needed to provide better functionality, new features, and improved performance. Maintaining compatibility leads, in the long run, to a kernel that gets buried under old cruft and which is increasingly unmaintainable. So, the explicit policy is to make the changes and deal with the pain immediately. It can be unpleasant for driver writers, but the result is a better kernel.

As for dealing with them...here's my blatant plug: Read the book. It covers kernels from 2.0 through 2.4.4, and shows how to write code that is portable across all of these versions. Each incompatibility must be dealt with individually, often through the definition of macros and wrapper functions to "backport" the 2.4 API to older kernels. It can be as simple as:

#define ioremap vremap

or as complicated as an extensive backport of the PCI bus layer.

Story: Are Linux device drivers becoming as plentiful as those for Windows and Mac platforms? In other words, can Linux users find the drivers they need for the bulk of their computing activity?

Corbet: I can't really claim a detailed knowledge of what's available for those other platforms -- I'm a Linux user, after all. But I'll try. Support for bleeding-edge new hardware is probably still better for Windows -- it's a rare vendor who will put a new widget out there without making sure it works with the dominant platform.

Linux is catching up though, and Linux users don't have to wait as long for support as they once had to. Vendors are more supportive of Linux development (by providing drivers themselves, or at least making the hardware documentation available), and the development community is larger. So, to answer your other question, Linux users will indeed almost always find the hardware support they need.

Story: Now that you've mentioned the development community, I'm curious about your view on how does the OS community respond to the need for new drivers. How do they manage to do such a good job of producing drivers for so many popular, and not so popular pieces of hardware?

Corbet: There are two ways, essentially, that new drivers are written:

  1. Somebody has a particular peripheral and wants it to work with Linux. This is the traditional "scratching an itch" method which is responsible for much of the free software code base.

  2. Drivers are written by vendors and contributed to the kernel. We are starting to see more code come in this way. If you make hardware, it is in your interest to have it work with Linux, and many manufacturers are beginning to understand that. A number of Linux companies -- hardware vendors and distributors -- also employ Linux hackers who, among other things, work on drivers. For them, too, better hardware support in Linux makes a great deal of business sense.

  3. .

Story: Can you give us any insights to the open-source process for creating these drivers? Is there any uniformity in code writing that everyone adheres to, or is it some guy who has a need writes the code and shares it? If it's the latter, how do users know if a new driver is "safe" for their system?

Corbet: Usually a driver gets written because (1) the vendor wants it out there, or (2) some guy somewhere needs it. Some of the Linux system vendors and distributors are also putting some effort into device driver development.

Linus Torvalds includes a coding standards document with the kernel source, but adherence to it is uneven. Driver code, in particular, can vary widely in its coding style and quality.

As for knowing whether it is "safe"... The normal technique for new kernel code, including drivers, is to announce its availability on the kernel mailing list. At that point, people will often look it over and point out anything they see that looks suspicious. Others will try it out, and get back with their experiences. If the driver has problems, and the original author will not address them, somebody else will often pick up the code and make a release with the fixes.

The result is that drivers are usually "safe." Problems get fixed quickly, and there's usually only so much that can go wrong to begin with. Drivers thus tend to get incorporated into the mainline kernel relatively quickly -- they are easy to verify, and, in any case, will not break things for people who do not use them.

Story: So, based on all of this, is writing drivers easier or harder these days?

Corbet: It is both easier and harder. It is easier in that a lot of the basic kernel subsystems have been redesigned to work in a more simple and safe way. The interfaces for access to system buses and setting up DMA operations, for example, are much cleaner and easier to use. The quality of the debugging tools is improving as well.

But the need to deal with concurrency and locking adds a distinct challenge. Avoiding race conditions and other concurrency-related bugs is tremendously difficult, and tracking down this type of bug is no fun. Fine-grained locking brings a great deal of complexity, but without it, scaling the kernel to large systems is difficult if not impossible.

Story: Last question, Jonathan. Where do you go to find unusual drivers? Newsgroups? Online directories? Is there a resource that you recommend?

Corbet: There is no single resource for drivers, really. If I were looking for something esoteric, I would look in Google, and through the kernel mailing-list archives. If it exists, it will probably turn up in one of those places.

Once you get more specific, though, there are certainly resources out there. For example, if you're working with a USB device, www.linux-usb.org is the most likely place to find information. If you're fighting with a laptop system, http://www.linux-laptop.net/ is the definitive resource. The up-and-coming ALSA sound system (which may see inclusion in the 2.5 kernel series) has a great deal of information at www.alsa-project.org.

Story: Jonathan, thanks for your time. I've learned a great deal during this conversation. I wish you the greatest success with the upcoming release of Linux Device Drivers, as well as your other endeavors.

Corbet: Thanks, I enjoyed it!

Derrick Story is the author of The Photoshop CS4 Companion for Photographers, The Digital Photography Companion, and Digital Photography Hacks, and coauthor of iPhoto: The Missing Manual, with David Pogue. You can follow him on Twitter or visit www.thedigitalstory.com.

Allen Noren is VP of Online Marketing at O'Reilly Media. He's been with the company since 1992 when one of his first jobs was to maintain the O'Reilly Gopher site. He was a founding member of the GNN team that built one of the first commercial web portals, and was part of the group that created Safari Books Online and SafariU. He is currently helping to drive O'Reilly's digital efforts.


Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.