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

Figure 6. The State machine transitions for a sound-card shadow driver. Those recorded for recovery
are shown in boldface .

hence its abstract state machine, not all inputs
must be logged. Instead, the shadow only records
inputs needed to return a driver to its state at
the time of failure. The shadow drops requests
that do not advance the driver's state or whose
impact has been superseded by later inputs, for
example transitions on a loop in the abstract
state machine.
Figure 6 shows an example of the state ma-
chine transitions for a sound-card driver. The
transitions, made when the kernel issues requests
to the driver, are numbered. The final state of the
sequence is S4, but there is a loop through state
S3. As a result, the shadow may drop requests 2
through 5 from its log, because they do not affect
the final state of the driver.
To implement this state machine, the shadow
driver maintains a log in which it records several
types of information. First, it tracks I/O requests
made to the driver, enabling pending requests to
be re-submitted after recovery. An entry remains
in the log until the corresponding request has been
handled. In addition, for connection-oriented driv-
ers, the shadow driver records the state of each
active connection, such as offset or positioning
information.
The shadow driver also records configuration
and driver parameters that the kernel passes into
the driver. The shadow relies on this information
to reconfigure the driver to its pre-failure state
during recovery. For example, the shadow sound-

card driver logs ioctl calls (command numbers and
arguments) that configure the driver.
For stateful devices, such as a hard disk, the
shadow does not create a copy of the device state.
Instead, a shadow driver depends on the fail-stop
assumption to preserve persistent state (e.g., on
disk) from corruption. In other cases, the shadow
may be able to force the device's clients to recreate
the state after a failure. For example, a windowing
system can recreate the contents of a frame buffer
by redrawing the desktop.
In many cases, passive-mode calls do no work
and the shadow returns immediately to the caller.
For example, the kernel maintains a queue of
outstanding requests to a disk driver, and hence
the shadow driver for an IDE disk does little in
passive mode. For the network shadow driver, too,
the Nooks object-tracking system performs much
of the work to capture driver state by recording
outstanding packets.
Opaque parameters can pose problems for
recovery as they did for isolation. However, the
class-based approach allows shadow drivers to
interpret most opaque pointers. The standardized
interface to drivers ensures that a client of the
interface that has no knowledge of a driver's
implementation can still invoke it. Hence, clients
must know the real type of opaque parameters.
The shadow implementer can use the same
knowledge to interpret them. For example, the
Linux Open Sound System interface defines