1. Devices Supported in User Mode
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:
The device can be directly
connected, connected on the network, or connected via a wireless
protocol such as Bluetooth. UMDF also supports software-only drivers.
The initial UMDF release includes the following sample UMDF drivers:
Skeleton— 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). This is the board we will be using for
our driver example developments for UMDF.
USB/Filter— A filter driver for the USB-FX2 device stack.
User Mode Drivers can
support 32-bit or 64-bit devices for any Windows hardware platform and
can be distributed on Windows Update. UMDF is currently supported for
Windows 7, Windows Vista, and Windows XP.
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.
2. UMDF Model Overview
A
UMDF driver runs in a driver host process that also hosts UMDF and a
run-time environment. Each such driver operates as part of a stack of
drivers that manage a device. The User Mode Drivers are loaded above the
Kernel Mode Drivers at the top of the stack. Because user mode
components do not have access to the system address space where the
system and Kernel Mode Drivers maintain I/O requests and other shared
data, the UMDF architecture includes components that communicate between
kernel mode and user mode. Figure 3.1 shows the overall architecture of the UMDF driver model.
Figure 3.1
shows two device stacks that service two different devices. Each device
stack includes a UMDF driver that runs in its own driver host process.
The figure includes the following components, described according to the
typical flow of an I/O request.
Applications.
The applications are clients of the drivers. These applications are
user mode processes that issue I/O requests through the Win32 File I/O
API. The Win32 functions call I/O routines in the Windows kernel.
Windows kernel.
The Windows kernel creates I/O request packets (IRPs) to represent the
user mode I/O requests and forwards them to the top of the Kernel Mode
Driver stack for the target device.
Reflector.
The reflector is a Kernel Mode WDM Filter Driver that is installed at
the top of the kernel mode device stack for each device that a UMDF
driver manages. The reflector manages communication between the kernel
mode components and the User Mode Driver host process. The reflector
forwards I/O, power, and Plug and Play messages from the operating
system to the driver host process, so that User Mode Drivers can respond
to I/O requests and participate in Plug and Play device installation,
enumeration, and management. The reflector also monitors the driver host
process to ensure that it responds properly to messages and completes
critical operations in a timely manner, thus helping to prevent driver
and application hangs. Microsoft provides the reflector.
Driver manager.
The driver manager creates and shuts down the driver host processes and
maintains status information about them. It also responds to messages
from the reflector. The driver manager runs as a Windows service and is
started during installation of the first device that has a UMDF driver.
One instance of the driver manager handles all of the driver host
processes. The driver manager must be running all of the time that any
device controlled by a UMDF driver is installed on the system. Microsoft
provides the driver manager.
Host process.
The host process is the process in which the User Mode Driver runs. It
is separate from the application process and the driver manager. It runs
in the security credentials of a LocalService account, although it is
not a Windows service. The host process contains the user mode device
stack for the device. The device stack is visible to all applications
across the system. Each instance of a device has its own device stack.
Currently, each instance has a separate driver host process, too.
The host process includes the following components:
The UMDF driver is an in-process component object model (COM) component that controls the hardware from user mode.
The
framework exposes the user mode DDI, which is a dynamic-link library
(DLL) of COM-style objects that support the presentation, flow, and
management of I/O, power, and Plug and Play requests to the driver.
The
run-time environment dispatches I/O requests, loads the driver,
constructs and destroys the user mode device stack, manages a user mode
thread pool, and handles messages from the reflector and the driver
manager.
The host process is a child process of the driver manager.
Kernel Mode Drivers.
Additional Kernel Mode Drivers can service each device. These device
drivers are supplied either by Microsoft or by the device writer.
2.1. UMDF Object Model
UMDF drivers are object
oriented and event driven. The driver and the framework create instances
of objects that are required to support the driver’s device. The driver
implements event callback interfaces to handle events that affect these
objects.
The objects and
interfaces are based on the COM programming pattern. UMDF uses only a
small subset of COM, specifically the COM lifetime model; it does not
depend on the entire COM infrastructure and run-time library. The UMDF
run-time environment loads the driver by reading information that is
stored in the registry under the WDF service key.
UMDF uses only the query-interface and reference-counting features of COM. Every UMDF interface derives from IUnknow and therefore supports the QueryInterface, AddRef, and Release methods by default. The AddRef and Release methods manage object lifetime. The QueryInterface method enables other components to determine which interfaces the driver supports.
2.2. 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 return 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.
Table 1 lists all the UMDF object types and the interfaces that UMDF implements on each type.
Table 1. UMDF Object Types
| Type of Object | Interfaces | 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 | Exposes a framework file object that was opened by the Win32 CreateFile function, through which applications can access the device. |
| | IWDFDriverCreatedFile | Exposes a framework file object that the driver created. |
| I/O queue | IWDFloQueue | 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 | IWDFloRequest | Exposes a request for device I/O. |
| I/O target | IWDFloTarget | 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 | IWDFUsbTargetDevice | Exposes a USB device object that is an I/O target. Inherits from IWdfloTarget. |
| 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 IWdfloTarget. |
The driver calls methods on these interfaces to perform operations on its objects. For example, UMDF implements the IWDFloRequest 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
device. 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.
