Driver development

This topic reviews some basic steps and guidelines to keep in mind when planning and developing device drivers. For a complete list of guidelines, see ``Guidelines for all kernel drivers''.

Device driver development requires more up-front planning than most application programming projects. At the very least, testing and debugging are more involved, and more knowledge about hardware is required. The following steps can be used as a general guide to driver development.

Preparation

• Learn about the hardware. Most of the information you need can be found in the documentation for the device, and should include

  • how the device sends interrupts

  • the range of addresses of the hardware board

  • return codes and software protocols recognized by the device

  • how the device reports hardware failures

• Test the hardware to make sure it is functioning. This is especially important for a newly-developed device.

• Design the software. Even though the overall structure of a driver is not the same as an application program, good structured design remains important. Data flow diagrams, functional specifications, and structure charts are all useful tools in driver development. Design documents should cover not only the driver contents, but also the contents of any utility programs that will be used with the driver.

• Select a software maintenance and tracking utility.

Implementation

• Select one of the sample drivers to use as a starting place for your driver. Using the sample driver as a template rather than writing your driver from scratch saves time and generally leads to a more robust driver.

• Globally change the prefix used in the sample driver to your driver prefix. This ensures that the sample externally visible driver symbols in the sample are renamed to unique names for your driver.

• Modify the initialization entry point routines first and test loading and accessing the driver.

• Write base-level routines before interrupt-level routines.

• If applicable to the device, write and test any associated firmware.

• Develop utilities such as disk formatting, network administration, and diagnostic programs at the same time as the driver.

Follow-up

• As much as possible, use the testing phase to create error conditions that exercise the driver's ability to handle them.

• Evaluate the driver's performance both in isolation and in a production environment where other drivers are installed. Regression testing should be performed to ensure that a new device driver does not affect other system functionality.

• Make sure documents affected by the creation of the driver are updated. These may include operator and diagnostic manuals and sales or ordering information. If the driver is to be installed by a customer, write and test installation and de-installation packages, as described in ``Packaging and installing SVR5 drivers''.