Programming Approach for UMDF Windows 7 Device Drivers

In his previous article, User Mode Driver Framework for Windows 7 Drivers, Ronald Reeves covered the overall architecture of UMDF. This article looks at the programming approach for developing Windows 7 UMDF drivers. He also discusses when it is appropriate to use the UMDF mode and when you should use the kernel mode driver framework to develop a Windows 7 device driver.

Like this article? We recommend

Like this article? We recommend

UMDF supports the development of drivers for protocol-based or serial bus-based devices, such as Universal Serial Bus (USB) devices and network-connected devices. For example, drivers for the following types of devices can be written in user mode:

Portable storage devices

Portable media players

USB bulk transfer devices

Auxiliary display devices

The device can be directly connected, connected on the network, or connected via a wireless protocol such as Bluetooth. The UMDF release includes the following sample UMDF drivers:

Skelton: A minimal driver that is intended for use as a template for driver development.

Echo: A simple software-only driver that shows the use of a serial I/O queue.

USB/FX2_Driver and USB/Echo Driver: Function drivers for the USB-FX2 board that was designed by Open Systems Resources, Inc. (OSR).

USB/Filter: A filter driver for the USB-FX2 device stack.

Drivers that require the following cannot be written as UMDF drivers; they must be written as kernel mode drivers:

Handling interrupts

Direct access to the hardware, such as direct memory access (DMA)

Strict timing loops

Use of nonpaged pool or other resources that are reserved for kernel mode

In addition, a UMDF driver cannot be a client of the Windows kernel or of a kernel mode driver.

UMDF Objects

UMDF manages a series of objects that are exposed to the user mode driver. UMDF creates some of these objects in response to application-triggered actions, such as an I/O request; the driver creates other objects by calling methods on UMDF interfaces.

For each type of object, UMDF defines one or more interfaces through which to manipulate instances of the object. The interfaces provide methods and properties. Methods define actions that can be taken on behalf of the object and returns a status to indicate whether they succeeded or failed. Property operations set and get the attributes of the object and cannot fail. Some interfaces are implemented by UMDF, and others are implemented by the driver. The following table lists all the UMDF object types and the interfaces that UMDF implements on each type.

Type of Object Interface Description

Base object

IWDFObject

Exposes a base object for use as the driver requires.

Device

IWDFDevice

Exposes an instance of a device object. A driver typically has one device object for each device that it controls.

Driver

IWDFDriver

Exposes the driver object itself. Every driver has one driver object.

File

IWDFFile

IWDFDriverCreateFile

Exposes a framework file object that was opened by the Win32 CreateFile function, through which applications can access the device.

Exposes a framework file object that the driver created.

I/O queue

IWDFIoQueue

Exposes an I/O queue, which controls the flow of I/O in the driver. A driver can have any number of I/O queues.

I/O request

IWDFIoRequest

Exposes a request for device I/O.

I/O target

IWDFIoTarget

Represents the next-lower driver in the device stack, to which the driver sends I/O requests.

Memory

IWDFMemory

Exposes memory that the driver uses, typically an input or output buffer that is associated with an I/O request.

USB device

IWDRUsbTargetDevice

Exposes a USB device object that is an I/O target. Inherits from IWdfIoTarget.

USB interface

IWDFUsbInterface

Exposes an interface on a USB device.

USB pipe

IWDFUsbTargetPipe

Exposes a USB pipe that is an I/O target. Inherits from IWDfIoTarget.

The driver calls methods on these interfaces to perform operations on its objects. For example, UMDF implements the IWDFIoRequest interface, and the driver calls methods in this interface to retrieve the parameters for the I/O request.

For the driver, devices, and queues, both the framework and the driver maintain objects. The driver-created objects are callback objects, on which the driver implements the callback interfaces that are required to service its devices.

A driver has one callback object, one device callback object for each device that it supports, and one queue callback object for each queue that it creates. The callback objects serve as the “context memory” for the driver.