Windows 7 : Windows Driver Foundation Architecture (part 1)

1. WDF Component Functions

WDF includes a suite of components that support the development, deployment, and maintenance of both Kernel Mode and User Mode Drivers. WDF components work with existing driver development tools to address the entire driver cycle of the following:

• Plan & Design: Driver Model—The WDF driver model supports the creation of object-oriented, event-driven drivers. By using WDF, driver writers can focus on their device hardware, rather than on the operating system. WDF drivers can be written for either kernel mode or user mode.

• Develop: Frameworks and Windows Driver Kit (WDK)—WDF defines a single driver model and includes frameworks for both Kernel Mode and User Mode Driver development. The frameworks provide the basic infrastructure to support the WDF model. They implement common features, provide intelligent defaults, and manage most interactions with the operating system.

  The Kernel Mode Driver Framework (KMDF) implements basic Kernel Mode Driver support features that are required by Windows and are common to all Kernel Mode Drivers.

  The User Mode Driver Framework (UMDF) provides functional support similar to that in the KMDF, but enables drivers for some types of devices to run in user mode instead of in kernel mode.

• Test: Tracing and Static Analysis Tools—Both the KMDF and the UMDF have built-in verification code and support integrated tracing through Event Tracing for Windows (ETW). The generated traces can help in debugging drivers during development and in diagnosing problems in released drivers. WDF drivers also work with the existing driver verifier. In addition, compile-time driver verification tools, such as PREfast and Static Driver Verifier (SDV), are also part of the WDF effort.

• Qualify: Driver Signing—WDF drivers are signed in the same way as Windows Driver Model (WDM) drivers.

• Deploy: Driver Installation Tools—WDF drivers are installed by using INF files and work with existing driver installation tools, including the Driver Install Frameworks (DIFx) tools.

• Maintain: Versioning—WDF supports versioning so that a single driver binary can run on any version of the operating system and use the same version of the framework on which it was built and tested.

2. Design Goals for WDF

Writing a Windows driver is not easy. The current Kernel Mode Driver development model Windows Driver Model (WDM) is complex and has serious limitations.

WDM requires that drivers be designed to manage interactions with the operating system, not just the device hardware. A simple WDM driver has thousands of lines of code, much of which implements common features that every driver must support. WDM drivers must use device-driver interfaces (DDIs) that are exported directly from the operating system kernel. These interfaces were designed for performance, not for ease of use. In many cases, the DDIs expose essential operating system data structures directly to the driver, thus increasing the chance that a driver error might crash or corrupt the system.

For some device types, port/miniport models implement much of the WDM code. However, Windows supports more than 10 such models and each is different. So the knowledge gained from writing a miniport driver for one type of device does not necessarily apply to writing a miniport driver for a different type of device.

Unlike Kernel Mode Drivers, User Mode Drivers have no common infrastructure that is comparable to WDM.

The following are the primary design principles underlying the WDF model:

• Separate the driver model from the core operating system components.

• Provide a user mode option for some device types.

• Implement common and default driver features so that driver developers can focus on their hardware.

• Make drivers event driven and define the events at a detailed level so that driver tasks are straightforward.

• Support Plug and Play and power management implementation for all drivers.

• Support a consistent installation process for both User Mode and Kernel Mode Drivers.

• Provide integrated tools, including built-in tracing and verification support, to help find and diagnose problems both during debugging and after release.

• Enable a single driver binary to work with several versions of the framework and the operating system.

3. Device and Driver Support in WDF

Table 1 lists the WDF support for various device classes and driver models in Windows 7. From this table, we can get a feel for the wide range of device types that Windows 7 supports. As we have mentioned earlier, this book is primarily about creating custom device drivers. That is, ones not normally supplied by Microsoft. Notice also the distribution of device types across the two driver modes—that is, Kernel Mode Driver Framework (KMDF) and User Mode Driver Framework (UMDF).

Table 1. WDF Device Support for Windows 7

Device Class/Driver Model	KMDF	UMDF	SDV	PREfast
Antivirus filters	No	No	Yes	Yes
CD-ROM device	Yes	No	Yes	Yes
Cell phones	No	Yes	No	Yes
Digital cameras	No	Yes	No	Yes
Display adapters	No	No	No	Yes
DSL/Cable modems	Yes	No	No	Yes
Ethernet devices	No	No	No	Yes
Keyboards and mouse devices	Yes	No	Yes	Yes
Modems	Yes	No	Yes	Yes
Other device (not listed here) that connect to a Protocol bus such as USB or IEEE 1394	No	Yes	No	Yes
PDAs	No	Yes	No	Yes
Portable media players	No	Yes	No	Yes
Printers	No	No	No	Yes
Scanners	No	No	No	Yes
SCSI/StorePort	No	No	No	Yes
Video capture devices	No	No	No	Yes

4. WDF Driver Model

The WDF driver model defines an object-oriented, event-driven environment in which driver code manages device-specific features and a Microsoft-supplied framework calls the driver to respond to events that affect operation of its device. The driver model includes the following:

• An object model that is implemented by both KMDF and UMDF.

• A Plug and Play and power management implementation that both frameworks use.

• An I/O model in which the frameworks handle interactions with the operating system and manage the flow of I/O, Plug and Play, and power management requests.

• A versioning strategy that applies to both Kernel Mode and User Mode Drivers.

• Consistent installation techniques for both Kernel Mode and User Mode Drivers.

This design has several important advantages:

• The frameworks implement common driver features and default behavior, thus making vendor-written drivers smaller and faster to develop and debug.

• Microsoft can change the operating system’s internal data structure without introducing driver incompatibilities.

• Driver developers and hardware vendors are better isolated from incremental changes in each new version or update of the operating system.

• Each framework can track the state of the driver, operating system, and device, thus eliminating much of the complex logic often required in a driver, particularly in respect to Plug and Play and power management.

The WDF model provides a consistent but extensible driver development interface. Both frameworks conform to conventions for naming, parameter types and usage, object hierarchy, and default. Features that are required by or common to all device types are part of each overall framework, so driver writers can apply knowledge gained from writing a driver for one device type to writing a driver for another device type.