Chapter 6: Device Drivers
evident that this is not very sparing on resources. Much system run time is needed to check the status of
peripherals, to the detriment of more important tasks.Interruptsare the better alternative. Each CPU providesinterrupt linesthat are shared between the individ-
ual system devices (several devices may also share an interrupt but I discuss this below). Each interrupt
is identified by a unique number, and the kernel makes aservice routineavailable for each interrupt used.Interrupts suspend normal system work, thus drawing attention to themselves. A peripheral raises an
interrupt when data are ready to be processed by thekernel or (indirectly) by an application program.
With this method the system need no longer constantly check whether new data are available because it
is notified automatically by the peripheral when this is the case.Interrupt handling and implementation are complex topics whose details are discussed separately in
Chapter 14.Device Control via Buses
Not all devices are addressed directly by I/O statements but via a bus system. How this is done varies
according to the bus and devices used. Rather than going into specific details, I describe the basic differ-
ences between the various approaches here.Not all device classes can be attached to all bus systems. For example, it is possible to connect hard disks
and CD writers but not graphic cards to an SCSI interface. However, the latter can be housed in PCI slots.
In contrast, hard disks must be attached to a PCI bus via another interface (typically IDE).The different bus types are calledsystemandexpansionbuses (I won’t bother with their technical details).
The differences in hardware implementation are not important for the kernel (and are therefore of no
relevance when programming device drivers). Only the way in which the buses and attached peripherals
are addressed is relevant.In the case of the system bus — a PCI bus on many processor types and system architectures — I/O
statements and memory mappings are used to communicate with the bus itself and with the devices
attached to it. The kernel also provides several commands for device drivers to invoke special bus func-
tions — querying a list of available devices, reading or setting configuration information in a uniform
format, and so on — that are platform-independent and that simplify driver development because their
code can be used unchanged on various platforms.Expansion buses such as USB, IEEE1394, and SCSI exchange data and commands with attached devices
by means of a clearly defined bus protocol. The kernel communicates with the bus itself via I/O state-
ments or memory mappings^3 and makes platform-independent routines available to enable the bus to
communicate with the attached devices.Communication with bus-attached devices need not be performed in kernel space in the form of a device
driver but in some cases may also be implemented from userspace. Prime examples are SCSI writers
that are typically addressed by thecdrecordtool. This tool generates the required SCSI commands,
sends them to the corresponding device via the SCSI bus with the helpof the kernel, and processes the
information and responses generated and returned by the device.(^3) Thebusesareoftenplug-incardsinaPCIslot and must be addressed accordingly.