Chapter 6: Device Drivers
URBs have not always been used to communicate and exchange data with USB devices. In earlier
versions of the USB system, there were various interfaces for each type of transfer — not something
that made the programming of device drivers any easier. In this old approach, the implementation of
isochronous transfers was riddled with errors. A group of kernel developers therefore decided not only
to totally rewrite the driver for the host adapter used at the time but also to fully redesign the entire USB
layer.^25 URBs are something of an oddity in the Linux kernel in the sense that their design was lifted from
the USB implementation of MS Windows, otherwise so unloved in Linux circles. There are differences in
detail, but the basic concept is the same in both operating systems. Of course, it goes without saying that
the Linux version has far fewer bugs...The exact layout of URBs is not particularly interesting for our purposes, so I will dispense with a close
examination of the associatedstruct urbstructure. The many references to the details of and difference
between the individual transfer types means that thestructure is difficult to understand without a com-
prehensive knowledge of USB data transfer, and a detailed description of the structure is beyond the
scope of this book.As it is, USB device drivers rarely come into contact withurbinstances but instead make use of a whole
set of macros and helper functions to facilitate filling in URBs for requests and the reading of returned
data. This requires in-depth knowledge of the operation of USB devices and is therefore not discussed
here.6.8 Summary
Device drivers comprise the largest part of the Linux kernel sources. Nevertheless, I did not consider the
implementation of individual drivers in this chapter, but focused on theframeworkprovided by the kernel
for this purpose instead. This is reasonable because device drivers can be seen as ‘‘kernel applications’’
that are built on top of this framework.You have learned that device drivers can essentiallybe grouped into two categories: Character devices
that transfer a stream of bytes to and from the kernel, and block devices that require a more complicated
request management. Both, however, do interact with userland applications by means of device special
files that allow them to access the services of drivers with regular file I/O operations.Finally, I have also discussed how I/O memory and port resources are handled by the kernel, and have
discussed how bus systems connect devices with the computer and with other devices. This also included
a presentation of the generic device and driver model, which allows both kernel and userspace applica-
tions to enjoy a unified picture of the available resources.(^25) In allusion to the date of the patch, the authors of the new layer refer to this rewrite as the ‘‘USB October revolution‘‘...