Driver Design Strategies

< BACK  NEXT >

[oR]

Like most software, drivers benefit from an organized approach to development. This section gives some guidelines that may help shorten development time.

Use Formal Design Methods

Traditionally, writing a device driver implied a license to code without a design strategy. In the haste to test brand new hardware, the unit test code became the basis for the ultimate driver. Perhaps, too, many device drivers were written by programmers unfamiliar with the operating system. The first driver written is really a journey of discovery as the driver author learns the overall I/O architecture of the system.

Fortunately (or perhaps sadly, depending on one's perspective), the days of software cowboys are over. Between complicated hardware and operating systems, there is no longer room for design-as-you-go coding. Writing Windows 2000 drivers certainly entails a steep learning curve. Good software engineering and practices are required for success.

A short list of design techniques, some of which are borrowed from real-time design methodology, are listed below.

• Data flow diagrams can help break a driver into discrete functional units. These diagrams make it easier to visualize how the functional units in a driver relate to each other, and how they transform input data into output data.

• State-machine models are another good way to describe the flow of control in a driver especially one that manages an elaborate hardware or software protocol. In the process of verifying the state machine, potential synchronization issues can be identified.

• An analysis of expected data arrival rates or mandatory input-to- output response will give a set of quantitative timing requirements. These are important to establish the overall performance goals of the driver.

• Another useful tool is an explicit list of external events and the driver actions that these events should trigger. This list should include both hardware events from the device and software I/O requests from users.

Using these techniques helps decompose a driver into well-defined functional units. In some cases, this might mean breaking a single, monolithic driver into a pair of port and class drivers that handle hardware-dependent and hardware-independent functions. In any event, the time spent analyzing the design of a driver at the start of the project more than pays for itself in reduced debugging and maintenance.

Use Incremental Development

Once an initial analysis and design is completed, it's time to start the actual development. Following the steps below can reduce debugging time by helping to detect problems while they're still easy to find.

1. Decide which kinds of kernel-mode objects a driver needs.

2. Decide what context or state information a driver needs, and decide where it will be stored.

3. Write the DriverEntry and Unload routines first. Do not initially add Plug and Play support. This allows for testing the driver manually using the Computer Management Console.

4. Add driver dispatch routines that process IRP_MJ_CREATE and IRP_MJ_CLOSE operations. These routines typically do not require device access. The driver can then be tested with a simple Win32 program that calls CreateFile and CloseHandle.

5. Add code that finds and allocates the driver's hardware, as well as code to deallocate the hardware when the driver unloads. If the hardware supports Plug and Play detection, this step tests the hardware and the driver's ability to automatically load.

6. Add dispatch routines that process any other IRP_MJ_XXX function codes. Initially, these dispatch routines should complete each I/O request without starting the physical device. Again, these new code paths can be tested with a simple Win32 program that makes ReadFile and WriteFile calls, as appropriate.

7. Finally, implement the real Start I/O logic, the Interrupt Service routine, and the DPC routine. Now the driver can be tested using live data and real hardware.

Another useful tip: When the exact behavior of hardware is unknown, add a DeviceIoControl function that gives direct access to the device registers. This allows a simple Win32 program to manipulate the device registers directly. Remember to disable this function before shipping the final version of the driver.

Examine and Use the Sample Drivers

The Windows 2000 Device Driver Kit (DDK) contains a considerable amount of sample code. There are many ways to use this code to make driver development easier. Microsoft encourages cutting and pasting from their sample source code. Of course, as usual, no warranty is implied or should be assumed when using this code.

< BACK  NEXT >