Plug and Play and Power Management

Seamless and robust handling of Plug and Play and power events is critically important to system reliability and a good user experience. A primary WDF design goal was to simplify the implementation of Plug and Play and power management support and make this support available to both UMDF and KMDF drivers.

WDF drivers are not required to implement the complicated logic that is required to track Plug and Play and power state. Internally, the framework supports a set of state machines that manage Plug and Play and power state for WDF drivers. The framework notifies WDF drivers of changes in Plug and Play and power state through a series of events, each of which maps directly to device-specific actions that the driver can perform.

WDF Design Criteria for Plug and Play and Power Management

WDF support for Plug and Play and power management is based on the following principles:

• The driver should not be required to interpret or respond to every Plug and Play or power management event.

  Instead, the driver should be able to "opt in" and handle only those events that are relevant to its device, with the framework handling the rest.

• WDF actions at each point must be well defined and predictable.

  In effect, a contract applies to each Plug and Play and power event that clearly defines the driver's responsibilities.

• Plug and Play and power management events should be based on a group of core state changes, power-up, and power-down.

  Actions should be added to that core to handle specific scenarios. For example, a Plug and Play stop action invokes the core power-down event plus a releasehardware event.

• Plug and Play and power management events should be related to a well-defined task.

  Drivers should not be required to track system state to determine how to respond to a particular event.

• The frameworks should provide default behavior for a rich set of Plug and Play and power features, including resource rebalancing, device stop, device removal, device ejection, fast resume, shutdown of idle devices, and device wake-up by external signals.

• A driver should be able to override any framework-supplied defaults.

• Plug and Play and power management should be thoroughly integrated with other parts of the framework, such as controlling the flow of I/O requests.

• The frameworks must support both simple and complex hardware and driver designs.

  Simple tasks should be easy to implement, but the framework should provide straightforward ways for developers to extend their design to handle complex tasks.

• The frameworks should be extensible and flexible at the appropriate points, so that drivers can respond to state changes with their own custom actions.

  For example, WDF supports self-managed I/O, which can be used to coordinate operations that are not related to queued I/O requests or are not subject to power management for such state changes.

The framework provides default processing for every Plug and Play and power event. This approach vastly reduces the number of decisions that a WDF driver is required to make-especially during power transitions. WDF drivers contain much less Plug and Play and power management code than WDM drivers. Some WDF software drivers do not require any Plug and Play and power management code at all.

Chapter 7, "Plug and Play and Power Management," provides details about how WDF handles Plug and Play and power state changes.