)
The Plug and Play (PnP) Manager communicates information and requests to device drivers via I/O request packets (IRPs) with a major function code of IRP_MJ_PNP. This type of request is new with Microsoft Windows 2000 and the Windows Driver Model: previous versions of Microsoft Windows NT required device drivers to do most of the work of detecting and configuring their devices. Happily, WDM drivers can let the PnP Manager do that work. To work with the PnP Manager, driver authors will have to understand a few relatively complicated IRPs.
Plug and Play requests play two roles in the WDM. In their first role, these requests instruct the driver when and how to configure or deconfigure itself and the hardware. Table 6-1 lists the roughly two dozen minor functions that a PnP request can designate. Only the bus driver handles the nine minor functions shown with an asterisk; a filter driver or function driver would simply pass these IRPs down the stack. Of the remaining minor functions, three have special importance to a typical filter driver or function driver. The PnP Manager uses IRP_MN_START_DEVICE to inform the function driver what I/O resources it has assigned to the hardware and to instruct the function driver to do any necessary hardware and software setup so that the device can function. IRP_MN_STOP_DEVICE tells the function driver to shut down the device. IRP_MN_REMOVE_DEVICE tells the function driver to shut down the device and release the associated device object. I'll discuss these three minor functions in detail in this chapter and the next; along the way, I'll also describe the purpose for the other unstarred minor functions that a filter driver or function driver might need to handle.
Table 6-1. Minor function codes for IRP_MJ_PNP. (* indicates handled only by bus drivers.)
| IRP Minor Function Code | Description |
|---|---|
| IRP_MN_START_DEVICE | Configures and initializes device |
| IRP_MN_QUERY_REMOVE_DEVICE | Can device be removed safely? |
| IRP_MN_REMOVE_DEVICE | Shuts down and removes device |
| IRP_MN_CANCEL_REMOVE_DEVICE | Ignores previous QUERY_REMOVE |
| IRP_MN_STOP_DEVICE | Shuts down device |
| IRP_MN_QUERY_STOP_DEVICE | Can device be shut down safely? |
| IRP_MN_CANCEL_STOP_DEVICE | Ignores previous QUERY_STOP |
| IRP_MN_QUERY_DEVICE_RELATIONS | Gets list of devices which are related in some specified way |
| IRP_MN_QUERY_INTERFACE | Obtains direct-call function addresses |
| IRP_MN_QUERY_CAPABILITIES | Determines capabilities of device |
| IRP_MN_QUERY_RESOURCES* | Determines boot configuration |
| IRP_MN_QUERY_RESOURCE_REQUIREMENTS* | Determines I/O resource requirements |
| IRP_MN_QUERY_DEVICE_TEXT* | Obtains description or location string |
| IRP_MN_FILTER_RESOURCE_REQUIREMENTS | Modifies I/O resource requirements list |
| IRP_MN_READ_CONFIG* | Reads configuration space |
| IRP_MN_WRITE_CONFIG* | Writes configuration space |
| IRP_MN_EJECT* | Ejects the device |
| IRP_MN_SET_LOCK* | Locks/unlocks device against ejection |
| IRP_MN_QUERY_ID* | Determines hardware ID of device |
| IRP_MN_QUERY_PNP_DEVICE_STATE | Determines state of device |
| IRP_MN_QUERY_BUS_INFORMATION* | Determines parent bus type |
| IRP_MN_DEVICE_USAGE_NOTIFICATION | Notes creation or deletion of paging, dump, or hibernate file |
| IRP_MN_SURPRISE_REMOVAL | Notes fact that device has been removed |
A second and more complicated purpose of PnP requests is to guide the driver through a series of state transitions, as illustrated in Figure 6-1. WORKING and STOPPED are the two fundamental states of the device. The STOPPED state is the initial state of a device immediately after you create the device object. The WORKING state indicates that the device is fully operational. Two of the intermediate states—PENDINGSTOP and PENDINGREMOVE—arise because of queries that all drivers for a device must process before making the transition from WORKING. SURPRISEREMOVED occurs after the sudden and unexpected removal of the physical hardware.
Figure 6-1. State diagram for a device.
When I described the standard model for IRP processing in the previous chapter, I indicated that Plug and Play would impose additional requirements on IRP queuing and cancellation. I'll describe a DEVQUEUE object in this chapter that satisfies those requirements and helps you manage the state transitions.