Plug and Play Technology

Properly implemented, Plug and Play provides automatic configuration of PC hardware and devices. For modern versions of Microsoft� Windows�, the system and its firmware must comply with Advanced Configuration and Power Interface Specification (ACPI). The driver architecture for Windows XP/2000 supports comprehensive, operating system-controlled Plug and Play.All drivers for all versions of the Microsoft� Windows� operating system should support Plug and Play. A major part of supporting Plug and Play is properly handing Plug and Play I/O request packets (IRPs). This article highlights the key rules that driver writers must follow when handling Plug and Play IRPs.

Plug and Play technologies are defined for IEEE 1394, PCI, PC Card/CardBus, USB, SCSI, ATA, ISA, LPT, and COM.
Each Plug and Play device must:
1) Be uniquely identified.
2) State the services it provides and resources it requires.
3) Identify the driver that supports it, and allow software to configure it.

Plug and Play drivers must adhere to the following rules:

1. All drivers must have a dispatch routine for handling Plug and Play IRPs.
   A driver sets the address of the routine in DriverObject->MajorFunction[IRP_MJ_PNP] in its DriverEntry routine. This dispatch routine can be a separate DispatchPnp routine that only handles Plug and Play IRPs, or the driver can handle several IRP_MJ_Xxx codes in a single Dispatch routine.



2. All function and filter drivers must pass Plug and Play IRPs down to the next-lower driver in the device stack unless such a driver fails the IRP.
   All drivers for a device must have the opportunity to handle Plug and Play IRPs for the device, unless a driver fails the IRP. The Plug and Play Manager sends IRPs to the top driver in a device stack. Function and filter drivers pass the IRP down to the next-lower driver and the underlying bus driver completes the IRP. For more information, see the following section, Passing Plug and Play IRPs Down the Device Stack.



3. All drivers must handle certain Plug and Play IRPs and may optionally handle others.
   Each Plug and Play driver is required to handle certain IRPs, such as IRP_MN_REMOVE_DEVICE, and can optionally handle others. See the Setup, Plug & Play, and Power Management Reference in the Windows NT 5.0 beta DDK documentation for information on which IRPs are required and optional for each kind of driver.
   A driver can fail a required Plug and Play IRP with an appropriate error status, but a driver must not return STATUS_NOT_SUPPORTED for a required IRP.



4. All drivers must handle a Plug and Play IRP in its Dispatch routine (on the IRP's way down the device stack), in an IoCompletion routine (on the IRP's way back up the device stack), or both, as specified in the reference page for the IRP.
   Some Plug and Play IRPs must be handled first by the driver at the top of the device stack and then by each next-lower driver, as is the case with IRP_MN_REMOVE_DEVICE. Some IRPs must be handled first by the underlying bus driver, as is the case with IRP_MN_START_DEVICE. Still other IRPs can be handled both on the way down the device stack and on the way back up, as is the case with IRP_MN_QUERY_CAPABILITIES. See the Setup, Plug and Play, and Power Management Reference in the Windows NT 5.0 beta DDK documentation for the rules that apply to each Plug and Play IRP.



5. Drivers must add information to an IRP on the IRP's way down the device stack and modify or remove information on the IRP's way back up.
   When returning information in response to a Plug and Play query IRP, drivers must follow this convention to enable orderly information passing by the layered drivers for a device.



6. Except where explicitly documented, drivers must not depend on Plug and Play IRPs being sent in any particular order.



7. When a driver sends a Plug and Play IRP, it must send the IRP to the top driver in the device stack.
   Most Plug and Play IRPs are sent by the Plug and Play Manager, but some can be sent by drivers. A driver must send a Plug and Play IRP to the driver at the top of the device stack. Call IoGetAttachedDeviceReference to get a pointer to the device object for the driver at the top of the device stack.