Even a virtual device driver like Wdm1 has a device stack. Wdm1 is a function driver and so its device object is an FDO. There is a bus driver underneath Wdm1, the system unknown driver. the unknown bus driver makes a PDO to represent each Wdm1 device. The Unknown driver does some important jobs, even though it does not correspond to a hardware bus. The following chapter describes the jobs that even a minimal bus driver like Unknown must do.
Figure 8.1 A bus driver, two devices, and their function drivers
Device Stacks
When one driver layers its device over another, it forms a
Figure 8.2 shows a generic device stack. A bus driver is always at the bottom of the stack. One or more function drivers do the main device control functions.
Filter drivers are used to modify the behavior of standard device drivers. Rather than rewrite a whole bus or class driver, a filter driver modifies its actions in the area of interest. As the figure shows, there are various types of filter driver. A bus filter driver acts on all devices that attach to a particular bus driver. Class filter drivers are installed in the stack for each device of the specified class. Finally, a device filter driver is installed for one particular device.
Filter drivers are only installed when a device is first installed, so they cannot be inserted once a device stack has been built.
Figure 8.2 Bus, function, and filter drivers
Monolithic and Layered Drivers
When a standard keyboard is found, Windows loads the appropriate driver. This talks directly to the keyboard through its controller electronics. The keyboard driver is described as
In contrast, USB drivers use a layered approach. To use a USB keyboard, the keyboard driver uses the services of the USB class drivers.
As shown in Chapter 21, the USB class drivers expose an upper edge that drivers higher than it must use. Such drivers can issue USB Request Blocks (URBs), which transmit or receive information from a USB device. The keyboard driver does not care how the USB class drivers do their job.
The situation for the USB class drivers themselves is probably slightly different[18]. They are told where the USB bus controller electronics live, and they make use of the services of the PCI bus driver. However, I suspect that the USB class drivers talk directly to their own hardware. Asking the PCI bus driver to write or read memory would be too slow.
A different approach would have been to let each USB driver talk directly to the USB hardware in a monolithic driver. This would lead to two problems. The first is that each USB driver would need a large amount of code. Duplicating this code would waste memory and writing large drivers is decidedly error prone. The second problem is almost of more significance: how would all these different drivers coordinate their activities? The answer is, of course, with difficulty. Using different layers of drivers solves both these problems.
Plug and Play Messages
This section looks at the messages that a PnP driver receives. Its AddDevice routine is called when a device is added. After that, messages are sent using the PnP IRP. The PnP messages have the same major function code IRP_MJ_PNP, but each message uses a different minor function code. Each message has different parameters in the IRP.
A PnP driver must implement an AddDevice routine and handle various PnP IRPs. Table 8.2 is a list of all the minor function codes. The first eight of these minor codes are the most important. The other minor function codes are usually just handled by bus drivers.
Table 8.2 Plug and Play minor function codes
| Common PnP IRPs | |
|---|---|
IRP_MN_START_DEVICE | Assign resources and start a device |
IRP_MN_QUERY_REMOVE_DEVICE | Ask if a device can be removed |
IRP_MN_CANCEL_REMOVE_DEVICE | Cancel a query remove request |
| IRP_MN_REMOVE_DEVICE | Device has been unplugged or uninstalled Deallocate resources and remove a device |
IRP_MN_SURPRISE_REMOVAL (W2000 only) | A user has unexpectedly unplugged a device |
IRP_MN_QUERY_STOP_DEVICE | Ask if a device can be stopped |
IRP_MN_CANCEL_STOP_DEVICE | Cancel a query stop request |
IRP_MN_STOP_DEVICE | Stop a device for resource reallocation |
| Unusual PnP IRPs | |
IRP_MN_QUERY_DEVICE_RELATIONS | Ask for PDOs that have certain characteristics |
IRP_MN_QUERY_INTERFACE | Let a driver export a direct-call interface |
IRP_MN_QUERY_CAPABILITIES | Ask about device capabilities (e.g., whether it can be locked or ejected) |
IRP_MN_QUERY_RESOURCES | Get a device's boot configuration resources |
