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

Table 1. The proxying actions of the shadow sound-card driver.

Request Action

read / write suspend caller

interrupt drop request

query capability ioctl answer from log

query buffer ioctl act busy

reset ioctl queue for later / drop duplicate

interface and the request semantics. In general,
the shadow will take one of five actions:

driver turns itself back on. The notion of being
“busy” in a driver interface simplifies active proxy-
ing. By reporting that the device is currently busy,
shadow drivers instruct the kernel or application
to block calls to a driver. The shadow network
driver exploits this behavior during recovery by
returning a “busy” error on calls to send packets.
IDE storage drivers support a similar notion when
request queues are full. Sound drivers can report
that their buffers are temporarily full.
The shadow sound-card driver uses a mix of
all five strategies for proxying functions in its
service interface. Table 1 shows the shadow's
actions for common requests. The shadow sus-
pends kernel read and write requests, which play
and record sound samples, until the failed driver
recovers. It processes ioctl calls itself, either by
responding with information it captured or by
logging the request to be processed later. For ioctl
commands that are idempotent, the shadow driver
silently drops duplicate requests. Finally, when
applications query for buffer space, the shadow
responds that buffers are full. As a result, many
applications block themselves rather than blocking
in the shadow driver.

1. Respond with information that it has recorded

in its log.

2. Report that the driver is busy and that the ker-

nel or application should try again later.

3. Suspend the requesting thread until the driver

recovers.

4. Queue the request for processing after re-

covery and return success.

5. Silently drop the request.

The choice of strategy depends on the caller's
expectations of the driver.
Writing the proxying code requires knowledge
of the kernel-driver interface, its interactions, and
its requirements. For example, the kernel may
require that some driver functions never block,
while others always block. Some kernel requests
are idempotent (e.g., many ioctl commands), per-
mitting duplicate requests to be dropped, while
others return different results on every call (e.g.,
many read requests). The writer of a shadow for
a driver class uses these requirements to select
the response strategy.
Device drivers often support the concept of be-
ing “busy.” This concept allows a driver to manage
the speed difference between software running
on the computer and the device. For example,
network drivers in Linux may reject requests and
turn themselves off if packets are arriving from
the kernel to quickly and their queues are full. The
kernel then refrains from sending packets until the

Shadow Driver Summary

Shadow drivers provide an elegant mechanism
that leverages the properties of device drivers
for recovery. Based on an abstract state machine
modeling an entire class of drivers, shadow
drivers monitor the communication between the
kernel and driver to obtain the driver state dur-