UMDF Operation and Default Code
[This topic applies to UMDF 1.x.]
A fundamental goal of the overall WDF model is to provide intelligent defaults, so that you can focus on your device hardware and avoid writing code to perform tasks that are common to most drivers. With UMDF, that type of code is built into the framework, so your drivers are smaller.
To achieve this goal, the UMDF is designed to work with drivers on an "opt-in" basis. A UMDF driver includes callback interfaces for only the events that affect its device. For example, some devices require intervention immediately after they are turned on and immediately before they are turned off. The driver for such a device can implement a callback interface that provides methods to be called at those times. If the device does not require such intervention, its driver does not implement the interface.
The "opt-in" approach is particularly valuable for Plug and Play (PnP) and power management features. Within WDF, PnP and power management are implemented as a state machine. (Both the UMDF and KMDF use the same implementation of the state machine.) At a given state, a predetermined set of events is valid for each type of object, and the framework calls the driver's callback functions for these events in a defined order. Thus, a driver can determine that both the system and its device are in a particular state whenever the driver is called to perform a PnP or power management action.
The complicated logic that tracks system and device state is incorporated into the framework, not into the driver. This approach reduces the amount of decision-making that is required in the driver and eliminates the need to perform the same task in numerous places. Instead, the framework defines a state-related event, and the driver supplies a callback interface. The driver includes code to handle only those events that its device requires device-specific support for. All other events can be handled by framework defaults.
PnP and power management support are integrated with queue management. A driver can configure power management support for its I/O queues so that the framework stops dispatching requests while the device is in a low-power state and resumes dispatching after the device has returned to the operational state. Similarly, if an I/O request arrives while the device is in a low-power state, the framework can automatically turn on the device.
Build date: 7/24/2013