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

Table 4. The observed behavior of several applications following the failure of the device drivers on
which they depend.

Application Behavior

Device Driver Application Activity Linux-Native Linux-Nooks Linux-SD

Sound mp3 player CRASH MALFUNCTION √

(audigy driver) audio recorder CRASH MALFUNCTION √

speech synthesizer CRASH √ √

strategy game CRASH MALFUNCTION √

Network network file transfer CRASH √ √

(e1000 driver) remote window manager CRASH √ √

network analyzer CRASH MALFUNCTION √

IDE compiler CRASH CRASH √

(ide-disk driver) encoder CRASH CRASH √

database CRASH CRASH √

process even though the exception occurred in the
kernel. This behavior is unique to Linux. Other
operating systems, such as Microsoft Windows
XP, deal with kernel processor exceptions more
aggressively by always halting the operating
system. In such systems, exceptions in sb would
cause system crashes.

into a device driver while an application using that
driver was running. Because both Linux-Nooks
and Linux-SD depend on the same isolation and
failure-detection services, their recovery capabili-
ties are differentiated by simulating failures that
are easily isolated and detected.

Application Survival Results
Table 4 shows the three application behaviors
observed. When a driver failed, each application
continued to run normally (√), failed completely
(“CRASH”), or continued to run but behaved
abnormally (“MALFUNCTION”). In the latter
case, manual intervention was typically required
to reset or terminate the program.
This table demonstrates that shadow drivers
( Linux-SD ) enable applications to continue run-
ning normally even when device drivers fail. In
contrast, all applications on Linux-Native failed
when drivers failed. Most programs running on
Linux-Nooks failed or behaved abnormally, il-
lustrating that restart recovery protects the kernel,
which is constructed to tolerate driver failures, but
does not protect applications. The restart recovery
manager lacks two key features of shadow drivers:
(1) it does not advance the driver to its pre-fail
state, and (2) it has no component to “pinch hit”

Application Survival

The previous section evaluated the ability of the
operating system to survive extension failures. This
section answers the question of whether applica-
tions that use a device driver continue to run even
after the driver fails and recovers. Shadow driver
recovery is tested in the presence of simple failures
to show the benefits of shadow drivers compared
to the simple restart recovery manager.
The crucial question for shadow drivers is
whether an application can continue functioning
following the failure of a device driver on which
it relies. To answer this question, the 10 applica-
tions in Table 3 were tested on each of the three
configurations, Linux-Native , Linux-Nooks , and
Linux-SD .
In each test, common driver bugs were simu-
lated by injecting a null pointer dereference bug