Programming Approach for UMDF Windows 7 Device Drivers
Like this article? We recommend
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.