Device Driver Reliability - Advanced Operating Systems and Kernel Applications - page 40

Figure 10. (a) Microsoft Windows User-Mode Driver Framework. Applications call standard Win32
I/O APIs, and the kernel I/O manager invokes a UMDF device object that forwards the request to user
mode. (b) Linux Userspace I/O (UIO) architecture. Applications link to driver libraries, which use the
Posix I/O APIs to communicate to the UIO manager in the kernel.

remove driver code from the kernel, and virtual
machine isolation of drivers.

devices with UMDF drivers, the I/O manager
sends requests to the reflector, which forwards
the request to a user-level runtime, which in turn
invokes the UMDF driver.
UMDF drivers are specified as a set of COM
(Component Object Model) interfaces. As a
result, UMDF simplifies driver development by
supporting the C++ language and by providing
runtime support for common driver operations.
However, it therefore cannot provide fault toler-
ance for existing kernel-mode drivers, which must
be written in C.
User-move driver support in Windows is
complicated by the existence of stacked drivers .
In this model, a device is served by a layered set
of drivers, each providing additional functionality.
For example, a driver for a USB device layer over
a generic USB interface driver, which layers over
a driver for the specific host interface attached to
the device. In UMDF, only the top-most driver in
a stack may execute at user-level; the rest must
execute in the kernel.

user-mode drivers

While drivers for most commodity operating
systems are written in kernel-mode, Windows,
Linux and MacOS X all have limited support
for user-mode drivers. This section describes the
support in Windows and Linux.

Microsoft Windows UMDF

In response to driver reliability problems, Mi-
crosoft implemented the User-mode Driver
Framework (UMDF) for Windows XP and Vista
(Microsoft, 2007).As shown in Figure 10a, UMDF
adds a reflector to the device driver stack that
forwards requests to a user-mode driver host
process . I/O requests from applications are sent
first to the I/O manager in the Windows kernel,
which dispatches requests to specific drivers. For