An Overview of Intermediate Drivers

< BACK  NEXT >

[oR]

Before moving into the intricacies of the implementation of intermediate drivers, a few definitions are in order. This section also explores some of the trade-offs inherent in using a hierarchical driver architecture.

Intermediate Drivers Defined

For the purposes of this chapter, an intermediate driver is any kernel-mode driver that issues I/O requests to another driver. Intermediate drivers are often not responsible for any direct, register-level manipulation of hardware resources. Instead, they depend on a lower-level device driver, such as the physical driver, to perform hardware operations. In fact, intermediate drivers can assume a wide variety of forms.

The term "intermediate driver" is so generic that it must be classified in order to provide useful information. The possible classifications depend on whether or not the driver conforms to the WDM model.

For WDM-compliant driver implementations, there are three kinds of drivers:

• Bus drivers

  Provide a hardware bus interface on a per slot basis and create one or more Physical Device Objects (PDOs).

• Function drivers

  Provide read, write, and other functional logic for an individual device. They create and manage one or more Functional Device Objects (FDOs)

• Filter drivers

  Provide modifications to an I/O request before presentation to lower layer drivers. Filters can be placed around the functional driver or on top of a bus driver.

Note the relationship between a bus driver and a physical device object. The bus driver constructs and manages PDOs and is therefore often called a physical driver.

Outside the WDM model, driver architectures can choose to use layered approaches in other ways:

• Filter drivers

  A driver can be written to transparently intercept requests intended for some other driver. This allows behavior modifications of an existing driver.

• Tightly coupled drivers

  This category includes drivers that define a private interface between them. The interface does not use the I/O Manager's calling mechanism for inter-driver communication.

With the exception of tightly coupled drivers, all intermediate drivers are a form of layered drivers. Later parts of this chapter explain how to develop drivers in each of these families.

When To Use a Layered Architecture

One early and important driver design issue is whether to implement the driver as a series of layers, or whether it should be structured as a single, monolithic unit. The following section provides the trade-offs of using a layered approach.

PROS OF LAYERED ARCHITECTURE

Depending on the goals, multiple driver layers can provide a number of benefits. Using layers allows the separation of higher-level protocol issues from management of the specific underlying hardware. This makes it possible to support a wider variety of hardware without having to rewrite large amounts of code. It also promotes flexibility by allowing the same protocol driver to plug into different hardware drivers at runtime. This is the approach taken by Windows 2000 network drivers.

If several different kinds of peripherals can all be attached to the same controller (as in the case of a SCSI adapter), layering allows the decoupling of the management of the peripheral from the management of the controller. To do this, a single device driver for the controller (the port driver) and separate higher-level class drivers for each type of attached peripheral must be written. The two main benefits are that the class drivers are smaller and simpler, and (assuming a well-defined protocol) the class and port drivers can come from different vendors.

The implementation of the USB and IEEE 1394 buses is based upon a layered approach for these exact reasons.

Layering also makes it possible to hide hardware limitations from users of the device, or to add features not supported by the hardware itself. For example, if a given piece of hardware can handle transfers only of a certain size, another driver that would break oversized transfers into smaller pieces might be stacked on top. Users of the device would be unaware of the device's shortcomings.

Inserting driver layers provides a transparent way to add or remove features from a product without having to maintain multiple code bases for the same product. Fault-tolerant disks are one example of this. They are implemented as a separate driver layer that is shipped with Windows 2000 Server but not with Windows 2000 Professional.

CONS OF LAYERED ARCHITECTURE

Of course, there is a downside to the use of a layered architecture. First, I/O requests incur extra overhead because each IRP has to take a trip through the I/O Manager every time it passes from one driver to another. To some extent, this overhead can be reduced by defining a private inter-driver interface that partially bypasses the I/O Manager.

It also takes somewhat more design effort to make sure that the separate driver components fit together seamlessly. In the absence of an external standard, this can be especially painful if some of the drivers are coming from different vendors.

Since the overall functionality is no longer contained in a single driver executable, there is somewhat more bookkeeping involved in managing the drivers.

This also has some impact on maintaining version compatibility between various members of a hierarchy.

Finally, installing layered drivers is slightly more involved since each must provide proper installation procedures. In addition, it is necessary to set dependency relationships among the various drivers in the hierarchy to make sure they start in the proper order.

< BACK  NEXT >