Specifications

Writing a User-Level Device Drive
r
17-3
Because of these limitations, it is intended that a user-level device driver be used only by
applications that execute in a controlled environment and have strict real-time
performance requirements.
Which Types of Devices Are Candidates for a User-Level Driver? 17
The types of devices that are candidates for development of a user-level device driver are
as follows:
• Devices that must be used by application programs that require minimal
overhead in accessing the device.
• Devices that require much application control over device registers or
control functions. If a kernel driver were used to control such a device, an
application program would be required to make many ioctl system calls
to access the device’s registers.
• Devices that are needed to perform a great deal of raw I/O (for example, a
serial line port, a raw storage device, and a communication channel). These
types of devices typically perform DMA transfers between the device and
physical memory.
What Affects the Complexity of a User-Level Device Driver? 17
The complexity of a user-level device driver varies according to the nature and capabilities
of the device that it controls and the extent to which it supports the capabilities of the
device. Some of the factors that affect the complexity of a user-level driver are as follows:
• Whether the device is a programmed I/O device or a DMA (Direct Memory
Access) device
• Whether the driver supports single-user or multiuser access to the device
• Whether the driver supports only polling or provides interrupt support
The extent to which each of these factors affects the complexity of the driver is described
in the sections that follow.
Programmed I/O versus Direct Memory Access Devices 17
Developing a user-level device driver for a programmed I/O device is simpler than
developing one for a DMA device. A programmed I/O device does not directly access
physical memory. Instead, the device supplies data to the CPU only when the CPU reads
the data directly from a device register. Data read from a programmed I/O device can be
placed in the user’s I/O buffer via the buffer’s virtual address, which is supplied on a call
to the driver’s read routine. With DMA devices, the application’s I/O buffer must be
locked in physical memory, and the physical location of that buffer must be supplied on a
call to the driver’s read routine. The manner in which an application’s I/O buffer is
handled for DMA devices is described in “User I/O Buffer Descriptor” on page 17-7.