Linux Device Drivers Updateby Derrick Story and Allen Noren
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.
Linux Device Drivers, 2nd Edition
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:
Zero-copy networking has already been sneaked into the 2.4.4 kernel. This technique, which aims to move data directly to a network interface from the user's buffer without copying it through the kernel, can greatly increase performance on high-end systems, but it requires that the network hardware (and its driver) support the technique.
The network driver interface will see further changes aimed at increasing performance in very high-traffic situations.
The zero-copy mechanism used by the networking code will likely be expanded and, in some unknown way, reconciled with the
kiobufcode to provide a more general support API for zero-copy transfers.
The block driver interface will be, in the words of one kernel developer, "rototilled." Numerous changes are required in this subsystem to provide the sort of performance that high-end enterprise applications need, and to better support facilities like journaling filesystems.
Support for ACPI power management will be included; it will require support from most of the device drivers in the system.
Hot-pluggable devices, such as USB devices, are already reasonably well supported in 2.4, but much more work will be done in this area. It is possible that the requirements of a much more dynamic hardware environment will force the abandonment, or at least the deprecation of the classic Unix "major and minor number" scheme for identifying devices.
I couldn't say how likely this is, but it could well be that, in 2.5, the Linux kernel becomes preemptable. Currently, kernel code will not be involuntarily scheduled out of the processor. This assurance has traditionally simplified kernel programming, but it can also create latency problems, where the system is unable to respond quickly enough to events. Making the kernel preemptable can solve this problem, but it brings a new set of locking problems to uniprocessor systems.
Device drivers for the Linux platform seem to be more plentiful than ever. What tricks do you have to make sure everything works when plugged into your Linux box?
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.
Pages: 1, 2