KMDF Overview

 KMDF  KMDF is a kernel-mode programming model that supports the development of filter, function, or bus drivers. The framework itself is a reentrant library that multiple drivers can share. Drivers bind dynamically to the library at load time. The system can support multiple side-by-side major versions of the framework, and each major version can support multiple drivers.

The framework handles the core tasks of a WDM driver and calls on the associated KMDF driver, implemented by the hardware vendor, to provide device-specific processing. By using KMDF, you can develop:

• Function drivers for Plug and Play devices.

• Filter drivers for Plug and Play devices.

• Bus drivers for Plug and Play device stacks.

• Certain types of miniport drivers, including NDIS-WDM, NDIS protocol, and Smartcard.

• Non-Plug and Play drivers for legacy devices that are not part of a Plug and Play stack-similar to legacy Windows NT 4.0-style drivers.

Drivers call a framework method during construction of the device stack to inform the framework of the driver type. In addition, function, filter, and bus drivers implement different sets of callback functions. For example, the bus driver typically supports callbacks to enumerate the children of the bus device. A function driver typically supports callbacks to manage I/O requests and its device's power state.

The KMDF DDI supports all types of drivers. However, some parts of the DDI are specifically intended for function, filter, or bus drivers. Also, some KMDF defaults differ depending on the type of driver, especially the default handling of I/O requests. For example, if a filter driver does not handle a request, the framework automatically passes the request to the next lower driver. If a function driver does not handle a request, the framework fails the request.

KMDF Objects

KMDF drivers implement callback functions, rather than the callback objects that UMDF uses. With KMDF, framework objects are created in the following ways:

• The framework creates the object and passes an object handle to the driver.

  For example, when the framework receives an I/O request, it creates an I/O request object and passes an object handle to the driver's EvtIoXxx callback routine.

• The driver creates the object by calling a framework object creation method.

  For example, the driver creates a framework device object by calling WdfDeviceCreate.

• Some objects, such as I/O request objects, are created by either the framework or the driver, depending on circumstances.

Framework objects expose two types of functions:

• Methods instruct the object to perform an action.

• Properties provide access to data.

  Generally each property consists of two methods; one method is called to read the data value and the other method is called to write a new value. Properties that do not allow both read and write access to the data have only a single method. The different methods are distinguished by naming conventions.

Chapter 5, "WDF Object Model," describes the KMDF naming conventions.

Evolutionary versus Revolutionary Changes

At first, the goal of KMDF was to evolve the driver model, making the problem easier in small steps over time. For me, two features shifted the goals of the framework toward a revolutionary change of the model. The first feature was the definition of a concrete object model. The object model revolutionized cleanup and freeing of resources, because it provided a clear contract on how the objects interacted with each other and the driver itself, freeing the driver from the requirement to track state and delete the objects manually.

The second feature was the introduction of the state machines for Plug and Play, power, and power policy. These state machines polarized the design of nearly all of the objects-especially I/O queues, I/O targets, and device-in the framework. By moving all state management to the framework, the code in the driver condensed down to operating on the hardware itself and not the operating system around it.

Like the object model, the state machines also defined a very clear contract on how the framework and driver should behave. Together, the object model and the state machines pushed the framework from taking a series of small steps over time to taking a very large leap immediately.
-Doron Holan, Windows Driver Foundation Team, Microsoft

KMDF Callback Functions

If a driver must handle one of the events that a framework object raises, it must implement a corresponding callback function and register it with the framework. The WDK convention for naming callback functions is EvtObjectEvent, where Object refers to the associated framework object and Event refers to the associated event. For example, when a device enters the D0 power state, the framework calls the driver's EvtDeviceD0Entry callback. However, these names are simply documentation conventions; you can name the event callback functions in your KMDF driver whatever you want.

Chapter 5, "WDF Object Model," provides guidelines for naming KMDF callback functions.