Linux Device Drivers Update
Pages: 1, 2
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:
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.
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..
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.