Writing Tightly Coupled Drivers

< BACK  NEXT >

[oR]

Unlike layered and filter drivers, tightly coupled drivers do not use the I/O Manager's IoCallDriver function to communicate with each other. Indeed, tightly coupled drivers do not need to conform to the strict stacking architecture that the WDM model constructs. Instead, they define a private calling interface. The advantage of this approach is that it is usually faster than the IRP passing model supported by the I/O Manager. In trade for improved performance, the mechanics of the interface between tightly coupled drivers is left as an implementation detail. As a result, it is difficult for tightly coupled drivers from different vendors to interoperate.

How Tightly Coupled Drivers Work

Since the interface between two tightly coupled drivers is completely determined by the driver designer, it is impossible to provide a single, unified description of how all tightly coupled drivers work. Instead, this section presents some general architectural guidelines. Figure 15.3 shows one common method of tightly coupling a pair of drivers.

Figure 15.3. Tightly coupled driver operation.

In Figure 15.3, the lower driver has exposed an interface. During the upper driver's initialization, the interface is retrieved from the lower driver using the PnP request IRP_MN_QUERY_INTERFACE. The interface is returned as a structure of data and function pointers. When the upper driver needs the services of the lower driver, it calls one of the functions in this structure directly, rather than using IoCallDriver. Before unloading, the upper driver calls another function in the interface, InterfaceDereference, to disconnect it from the lower driver.

Initialization and Cleanup in Tightly Coupled Drivers

The following sections describe in general terms how a pair of tightly coupled drivers might initialize and unload. Of course, the exact steps vary depending upon the driver design.

Lower AddDevice Routine

The "lower" driver acts as a server for the upper driver, exposing an interface that is used by this "client." The following steps describe the work performed by the lower driver.

1. Using the technique discussed in chapter 9, the lower driver exposes an interface using IoRegisterDeviceInterface. The interface exposed has a unique GUID and the interface structure is known to all clients a priori, including the higher driver.

2. The lower driver enables the exposed interface by calling IoSetDevice-InterfaceState.

3. The lower driver performs normal operations, awaiting the connection to its interface by the upper driver.

Upper AddDevice Routine

The upper driver, acting as a client of the server lower driver, performs the following steps:

1. It calls IoGetDeviceObjectPointer to obtain a reference to the lower device object. Since this routine also returns a corresponding File object pointer that is "counted," the File object pointer is usually dereferenced by using ObDereferenceObject.

2. Using the Device object pointer returned by IoGetDeviceObjectPointer, a call to IoGetDeviceInterface confirms the existence of the requested interface, by GUID, in the lower driver.

3. Using IoCallDriver, an IRP is sent to the lower device with IRP_MJ_PNP, minor subcode IRP_MN_QUERY_INTERFACE, to obtain the requested interface. The interface is returned as a structure of data and function pointers.

4. The higher driver calls InterfaceReference, a required function pointer entry within the interface. This function allows the lower driver to keep track of clients of its exposed interface.

5. The higher driver calls any other method of the interface, or may choose to read or write data exposed by the interface.

Upper RemoveDevice Routine

When the upper driver no longer requires use of the interface, typically during RemoveDevice, the higher driver calls InterfaceDereference to release its use of the interface on the lower driver.

Lower RemoveDevice Routine

The lower driver must call IoSetDeviceInterfaceState to announce that its interface is no longer available for clients. If any clients are connected to an interface at the time RemoveDevice is invoked, the lower driver must determine an appropriate course of action. For example, it may need to forcibly disconnect clients by freeing resources reserved on their behalf. Otherwise, the lower driver can reject the RemoveDevice request.

< BACK  NEXT >