This topic reviews some basic steps and guidelines
to keep in mind when planning and developing
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
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.
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.
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
Make sure documents affected by the creation of the driver are updated.
These may include operator and diagnostic manuals and sales or ordering
If the driver is to be installed by a customer, write
and test installation and de-installation packages, as
``Packaging and installing SVR5 drivers''.
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005