WDM与KMDF的区别

Differences Between WDM and KMDF

This topic has not yet been rated

The WDM model is closely tied to the operating system. Drivers interact directly with the operating system by calling system service routines and

manipulating operating system structures. Because WDM drivers are trusted kernel-mode components, the system provides limited checks on driver input.

In comparison, the KMDF model focuses on the driver’s requirements, and the framework library handles the majority of the interactions with the system. The

framework intercepts I/O requests, takes default actions where appropriate, and invokes the driver’s callbacks as required. The KMDF model is object based

and event driven. Objects represent common driver constructs, such as a device, a lock, or a queue. The driver thus contains an entry point (DriverEntry), the

event-related callback functions that are required to service the device and support I/O, and any additional internal utility functions on which the

Object Context Area

Supported IRP Types

I/O Queues

Synchronization and Concurrency

Driver Installation

Driver Structure

Both WDM and framework-based drivers contain a DriverEntry routine, a number of routines that are called to handle particular I/O requests, and various

support routines. In a WDM driver, the I/O dispatch routines map to particular major IRP codes. The dispatch routines receive IRPs from the I/O manager,

parse them, and respond accordingly. For a framework-based driver, the framework registers its own dispatch routines, which receive IRPs from the I/O

manager, parse them, and then invoke the driver’s event callback functions to handle them. The event callback functions typically perform a more specific task

Callbacks to handle the Plug and Play and power events that the driver supports.

Callbacks to handle the WMI requests that the driver supports.

Additional callbacks, as appropriate, for object cleanup, file creation, and I/O targets, and so on.

Device Objects and Driver Roles

Both WDM and KMDF drivers create one or more device objects. Each device object represents a driver role that is the target of I/O requests. A physical

device object (PDO) represents a bus driver, a functional device object (FDO) represents a function driver, and a filter device object (filter DO) represents a filter

driver.

In WDM drivers, these driver roles are implicit, so the driver must keep track of which role each device object represents and respond to IRPs appropriately.

Framework-based drivers, however, indicate explicitly whether a device object represents a PDO, FDO, or filter DO and register event callbacks that are specific

to that role. For example, PDOs are the target of resource requirements queries and device ejection requests, whereas FDOs and filter DOs do not handle

must set an I/O completion routine, pass the IRP down the stack, and process it after lower drivers. A framework-based driver simply implements the

corresponding callback routine, and the framework calls it after lower drivers have completed processing.

For information on how to create framework device objects, see Creating a Framework Device Object.

Some drivers also handle certain I/O requests that are independent of Plug and Play. A WDM driver creates a DEVICE_OBJECT as the target for such requests,

but does not attach it to the Plug and Play device stack. To accomplish the same result, a KMDF driver creates a control device object. Some framework-

based drivers use control device objects to implement “sideband” I/O mechanisms so that they can receive certain types of I/O requests regardless of device

state.

Object Model

KMDF supports a coherent object model in which objects are opaque to drivers, provide driver-configurable context areas, and are referenced by a handle.

WDM objects are system-wide objects that are accessible to drivers and are referenced by pointers. A driver that corrupts a WDM object can corrupt the