WDF Architecture

The WDF architecture is designed so that the frameworks mediate most interactions between the driver and Windows and between the driver and its device. This section discusses WDF architecture and how the principal components interact with a driver to handle I/O requests and perform other essential tasks. The following two sections summarize how this architecture is implemented for UMDF and KMDF drivers.

Figure 4-1 shows a conceptual view of the WDF architecture.

Figure 4-1: Conceptual view of the WDF model

Applications

Applications usually interact with a WDF driver just as they would with a WDM driver. An application obtains a device handle in the usual way and calls the appropriate Windows API functions to send requests to the device. For most purposes, an application does not know or need to know whether it is communicating with a WDM or with a WDF driver.

Applications and UMDF Drivers

In UMDF one of our main goals was that an application shouldn't be able to tell the difference between a user-mode and a kernel-mode driver. This is a big win over some of the other device class-specific user-mode models, which apply only to a particular type of device and which require applications to be modified before they can use the driver.

We weren't able to keep the transparency everywhere. For example, we allow all three transfer modes for I/O controls, but we can't provide client address space access to the driver, so some aspects of direct and neither I/O aren't available. We added a new status code that can be returned from an I/O operation to tell the application that the driver process terminated while handling the I/O. To enable impersonation, the application must change the way it calls CreateFile to allow the driver to impersonate the user. But aside from this, a UMDF driver should be indistinguishable from a KMDF driver from the application's point of view.
-Peter Wieland, Windows Driver Foundation Team, Microsoft

Kernel Subsystems

These subsystems-I/O manager, PnP manager, and so on-are the same as those that interact with WDM drivers. From the perspective of these subsystems, the framework is a WDM driver that is represented by a WDM device object. The services receive requests from applications and use IRPs to communicate the requests to the framework. When the request is complete, the services return the results to the application.

The Framework's Upper Edge

The upper edge of the framework operates as an abstraction layer between Windows and the driver. A driver can obtain most of the Windows services it requires by calling the framework DDI. However, a driver can call Windows functions if it requires services that the framework DDI does not provide.

The framework includes the following three key models, which govern how most driver tasks are handled:

• The object model governs how framework objects are created and managed.

• The I/O model governs how I/O requests are managed.

  For read, write, and device I/O control requests, the framework receives an IRP from Windows, repackages the data in the object model format, and passes it to the WDF driver for processing. When the driver has finished its processing, it returns the request to the framework. When a request is complete, the framework completes the IRP and returns the results to the I/O manager, which eventually returns the results to the application.

• The Plug and Play and power model governs how Plug and Play and power state changes are managed.

  WDF drivers are not required to implement a complex state machine to track Plug and Play and power state and to determine the correction action to take when the state changes. For Plug and Play and power management requests, the framework state machines determine what action is required based on the particular Plug and Play or power IRP that was received and the current system state. The model includes a set of events that map directly to device-specific actions. Drivers register callbacks for only those events that are important to their device and let the frameworks handle the remainder.

Framework Objects

The framework objects are the basic building blocks of a WDF driver. They represent common driver constructs such as the device, memory, I/O queues, and so on. Drivers interact with the objects through well-defined interfaces. These objects are either created by the framework and passed to the driver or are created by the driver by using methods that the framework exposes.

Driver Callbacks

For events of interest, drivers override the framework's default processing and provide their own event processing. To override the framework's default processing for an event, the driver implements and registers a callback. When the event occurs, the framework invokes the callback and passes the driver any related data. The driver handles the event and returns the results to the framework.

When to Implement a Callback

I always like to say that WDF's default handling for events will provide you with a perfectly functional driver all on its own. You only need to override that default behavior if you want to make the driver do something interesting.
-Peter Wieland, Windows Driver Foundation Team, Microsoft

The Framework's Lower Edge

Drivers must often communicate with their device or other drivers, for example:

• To communicate with another driver, a WDF driver uses a framework object called an I/O target object.

  The frameworks handle the mechanics of passing requests to the other drivers and returning any results to the WDF driver.

• KMDF drivers use the framework's DMA objects to manage transferring data to and from devices that support DMA.

  UMDF drivers do not communicate directly with devices. Instead, the framework passes requests to associated kernel-mode drivers, which handle the data transfer.