Specifications

15-1
15
Chapter 15Driver Testing and Debugging
15
15
15
Introduction 15
Testing a device driver consists of installing the driver on a working system and attempt-
ing to try all of its functions under a variety of operating conditions. Debugging a driver is
largely a process of analyzing the code to determine what could have caused a given
problem. The UNIX system includes some tools that can help, but because the driver oper-
ates at the kernel level, these tools can only provide limited information.
This chapter describes the tools that are available for testing and debugging the installed
driver and explains how to use them. This chapter also discusses some of the common
errors in drivers and some of the symptoms that can identify each.
During the first phases of test, remember that your driver code is probably not perfect, and
that bugs in the driver code can panic or damage the system, even parts of the system that
seem unrelated to the driver. Testing should be done when no other users are on the system
and all production data files are backed up. Alternatively, testing could be performed on a
restricted use system setup specifically for the purpose of testing drivers.
You should test the functionality of the driver as you write it. It is useful to install and test
the driver as soon as the initialization routines and the read/write routines are opera-
tional. This testing could involve writing a short program that only reads and writes to the
device to ensure that you can get into the device. When all the routines for the driver are
written, you should install the hardware for full functionality testing.
The UNIX system provides tools to help you, such as crash(1M), which is used either
for a post-mortem analysis after a system failure or for interactive monitoring of the driver.
Preparing a Driver for Debugging 15
The process of testing driver functionality is piecemeal: you have to take small pieces of
your driver and test them individually, building up to the implementation of your complete
driver.
Driver routines should be written and debugged in the following order:
1. init(D2), start(D2)
2. open(D2), close(D2)
3. intr(D2) interrupt routines