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

Table 3. The applications used for evaluating shadow drivers.

Device Driver Application Activity

Sound mp3 player ( zinf ) playing 128kb/s audio

(audigy driver) audio recorder ( audacity ) recording from microphone

speech synthesizer ( festival ) reading a text file
strategy game ( Battle of Wesnoth )

Network network file transfer ( scp ) of a 1GB file

remote window manager ( vnc )
network analyzer ( ethereal ) sniffing packets

Storage compiler ( make/gcc ) compiling 788 C files

(ide-disk driver) encoder ( LAME ) converting 90 MB file .wav to .mp3

database ( mySQL ) processing the Wisconsin Benchmark

ing tests, while the third untars and compiles a
number of files.
To measure isolation, test trials inject faults
into extensions running under two different Linux
configurations, both running the Linux-Nooks
kernel. In the first, called “native,” the Nooks
isolation services were present but unused. In
the second, called “Nooks,” the isolation services
were enabled for the extension under test. For
each driver, 400 trials inject five random faults
into the driver and exercised the system. Not all
fault-injection trials cause faulty behavior, e.g.,
bugs inserted on a rarely (or never) executed path
will rarely (or never) produce an error.
A system crash is the most extreme and easiest
problem to detect, as the operating system pan-
ics, becomes unresponsive, or simply reboots.
In an ideal world, every system crash caused by
a fault-injection trial under native Linux would
result in a recovery under Nooks. As previously
discussed, in practice Nooks may not detect or
recover from certain failures caused by very bad
programmers or very bad luck.
Figure 7 shows the number of system crashes
caused by the fault-injection experiments for
each of the extensions running on native Linux
and Nooks. Of the 333 crashes observed with
native Linux, Nooks eliminated 332, or 99%. In
the remaining crashes, the system deadlocked

when the driver went into a tight loop with inter-
rupts disabled. Nooks does not detect this type
of failure.
In addition, 206 trials caused applications to
fail without crashing the system under native
Linux. Nooks was able to reduce this to 102 ap-
plication failures. These failure manifest as the
driver misbehaving, but not performing illegal
operations. Nooks generally does not detect such
problems (nor is it intended to). However, when
Nooks' simple failure detectors do detect such
problems, its recovery services can safely restart
the faulty extensions.
Figure 7 also illustrates a substantial differ-
ence in the number of system crashes that occur
for sb driver under Linux, compared to e1000 ,
pcnet32 , and ide-disk . This difference reflects the
way in which Linux responds to kernel failures.
The e1000 , pcnet32 and ide-disk extensions are
interrupt oriented , i.e., kernel-mode extension
code is run as the result of an interrupt. The sb
driver is process oriented , i.e., kernel-mode ex-
tension code is run as the result of a system call
from a user process. Linux treats exceptions in
interrupt-oriented code as fatal and crashes the sys-
tem, hence the large number of crashes in e1000 ,
pcnet32 , and ide-disk) . Linux treats exceptions in
process-oriented code as non-fatal, continuing
to run the kernel but terminating the offending