Device Driver Reliability - Advanced Operating Systems and Kernel Applications - page 18

ers, maintain a single hardware configuration and
process each request independently. In contrast,
connection-oriented drivers maintain separate
hardware and software configurations for each
client of the device. Furthermore, requests on a
single connection may depend on past requests
that changed the connection configuration.
Devices attach to a computer through a bus ,
such as PCI (Peripheral Component Interconnect)
or USB (Universal Serial Bus), which is respon-
sible for detecting attached devices and making
them available to software. When detected, the
operating system locates and loads the appropri-
ate device driver. Communication between the
driver and its device depends on the connection
bus. For PCI devices, the driver communicates
directly with the device through regions of the
computer's physical address space that are mapped
onto the PCI bus or through I/O ports. Thus, loads
and stores to these addresses and ports cause
communication with a device. For USB devices,
drivers create request packets that are sent to the
device by the driver for the USB bus.
Most drivers rely on three types of communi-
cation with devices. First, drivers communicate
control information, such as configuration or I/O
commands, through reads and writes to device
registers in ports or I/O memory for PCI devices
or through command messages for USB devices.
Device registers are a device's interface to share
information and to receive commands from a
driver. Second, drivers communicate data through
DMA (Direct Memory Access) by instructing the
device or bus to copy data between the device and
memory; the processor is not involved in copy-
ing, reducing the processing cost of I/O. Finally,
devices raise interrupts to signal that they need
attention. In response to an interrupt, the kernel
schedules a driver's interrupt handler to execute. In
most cases, the interrupt signal is level triggered ,
in that an interrupt raised by the device is only
lowered when the driver instructs the device to do
so. Thus, interrupt handling must proceed before
any normal processing, because enabling inter-

rupts in the processor will cause another interrupt
until the driver dismisses the interrupt.
Device drivers can be modeled as abstract state
machines; each input to the driver from the kernel
or output from the driver reflects a potential state
change in the driver. For example, the left side of
Figure 1(b) shows a state machine for a network
driver as it sends packets. The driver begins in state
S0, before the driver has been loaded. Once the
driver is loaded and initialized, the driver enters
state S1. When the driver receives a request to send
packets, it enters state S2, where there is a packet
outstanding. When the driver notifies the kernel
that the send is complete, it returns to state S1.
The right side of Figure 1(b) shows a similar state
machine for a sound-card driver. This driver may
be opened, configured between multiple states, and
closed. The state-machine model aids in designing
and understanding a recovery process that seeks
to restore the driver state by clarifying the state
to which the driver is recovering. For example,
a mechanism that unloads a driver after a failure
returns the driver to state S0, while one that also
reloads the driver returns it to state S1.

nooKS reliability layer

Nooks is a reliability layer that seeks to greatly
enhance OS reliability by isolating the OS from
driver failures. The goal of Nooks is practical:
rather than guaranteeing complete fault tolerance
through a new (and incompatible) OS or driver
architecture, Nooks seeks to prevent the vast
majority of driver-caused crashes with little or no
change to existing driver and system code. Nooks
isolates drivers within lightweight protection
domains inside the kernel address space, where
hardware and software prevent them from corrupt-
ing the kernel. After a driver fails, Nooks invokes
shadow drivers, a recovery subsystem, to recover
by restoring the driver to its pre-failure state.