Chapter 6: Plug and Play for Function Drivers

Chapter 6

Plug and Play for Function Drivers

The Plug and Play (PnP) Manager communicates information and requests to device drivers via I/O request packets (IRPs) with the major function code IRP_MJ_PNP. This type of request was new with MicrosoftWindows 2000 and the Windows Driver Model (WDM): 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 a 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 which 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 of 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

Configure and initialize device

IRP_MN_QUERY_REMOVE_DEVICE

Can device be removed safely?

IRP_MN_REMOVE_DEVICE

Shut down and remove device

IRP_MN_CANCEL_REMOVE_DEVICE

Ignore previous QUERY_REMOVE

IRP_MN_STOP_DEVICE

Shut down device

IRP_MN_QUERY_STOP_DEVICE

Can device be shut down safely?

IRP_MN_CANCEL_STOP_DEVICE

Ignore previous QUERY_STOP

IRP_MN_QUERY_DEVICE_RELATIONS

Get list of devices that are related in some specified way

IRP_MN_QUERY_INTERFACE

Obtain direct-call function addresses

IRP_MN_QUERY_CAPABILITIES

Determine capabilities of device

IRP_MN_QUERY_RESOURCES*

Determine boot configuration

IRP_MN_QUERY_RESOURCE_REQUIREMENTS*

Determine I/O resource requirements

IRP_MN_QUERY_DEVICE_TEXT*

Obtain description or location string

IRP_MN_FILTER_RESOURCE_REQUIREMENTS

Modify I/O resource requirements list

IRP_MN_READ_CONFIG*

Read configuration space

IRP_MN_WRITE_CONFIG*

Write configuration space

IRP_MN_EJECT*

Eject the device

IRP_MN_SET_LOCK*

Lock/unlock device against ejection

IRP_MN_QUERY_ID*

Determine hardware ID of device

IRP_MN_QUERY_PNP_DEVICE_STATE

Determine state of device

IRP_MN_QUERY_BUS_INFORMATION*

Determine parent bus type

IRP_MN_DEVICE_USAGE_NOTIFICATION

Note creation or deletion of paging, dump, or hibernate file

IRP_MN_SURPRISE_REMOVAL

Note 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.

Figure 6-1. State diagram for a device.

I introduced my DEVQUEUE queue management routines in the preceding chapter. The main reason for needing a custom queuing scheme in the first place is to facilitate the PnP state transitions shown in Figure 6-1 and the power state transitions I ll discuss in Chapter 8. I ll describe the DEVQUEUE routines that support these transitions in this chapter.

This chapter also discusses PnP notifications, which provide a way for drivers and user-mode programs to learn asynchronously about the arrival and departure of devices. Properly handling these notifications is important for applications that work with devices that can be hot plugged and unplugged.

I ve devoted a separate chapter (Chapter 11) to bus and multifunction drivers.

TIP
You can save yourself a lot of work by copying and using my GENERIC.SYS library. Instead of writing your own elaborate dispatch function for IRP_MJ_PNP, simply delegate this IRP to GenericDispatchPnp. See the Introduction for a table that lists the callback functions your driver supplies to perform device-specific operations. I ve used the same callback function names in this chapter. In addition, I m basically using GENERIC s PnP handling code for all of the examples.



Programming the Microsoft Windows Driver Model
Programming the Microsoft Windows Driver Model
ISBN: 0735618038
EAN: 2147483647
Year: 2003
Pages: 119
Authors: Walter Oney

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net