Specifications

Writing a User-Level Device Drive
r
17-5
different types of driver routines that can be provided is presented in “Overview of User-
Level Device Driver Routines” on page 17-9; the standard error codes that can be returned
by the driver routines are described in “Overview of Error Returns” on page 17-13. An
overview of the device configuration program is provided in “Overview of the Device
Configuration Program” on page 17-14. Interrupt-handling and synchronization issues that
affect development of the components of a user-level device driver are discussed in “Over-
view of Interrupt-Handling Issues” on page 17-11 and “Overview of Synchronization
Issues” on page 17-12.
A user-level device driver that enables you to access a DR11W emulator directly from
user space is available as a separate product from Concurrent Computer Corporation.
Some of the examples used in this chapter are drawn from the DR11W user-level driver.
Overview of Data Structures 17
User-level device drivers can require that you define certain types of data structures.
“Shared Memory Regions” on page 17-6 describes the types of shared memory regions
that can be created. “User I/O Buffer Descriptor” on page 17-7 describes the user I/O
buffer descriptor that can be supplied on calls to user-level driver I/O routines.
In writing a user-level device driver, you should take into account two types of data:
private data and shared data. Private data are relevant only to the currently running
process; they are maintained in the currently running process’s data region. If a process
opens a device controlled by a user-level driver for debugging purposes, for example, the
flag that indicates that the device has been opened in debug mode is private data. Other
examples of private data include a device descriptor, pointers to shared user-level driver
data, and information about the currently running process (the process’s PID, for
example). Private data can be accessed or modified only by the currently running process.
Shared data are relevant to all processes that are using a particular device; they are
maintained in shared memory regions that can be accessed by all processes that open the
device. Such data include the current status of the driver (that is, whether or not the device
has been opened) and the current status of an I/O operation (for example, whether or not a
DMA transfer is in progress). If a device controlled by a user-level driver is performing a
DMA operation, for example, the flag that indicates that the device is busy is shared data--
it must be accessible to all processes that want to initiate a DMA operation. Shared data
can be modified by concurrently or sequentially executing user applications and if
applicable, by a user-level interrupt routine.
Distinguishing between private and shared data is important for synchronization purposes.
A user-level driver can modify private data without regard for other processes. To modify
shared data, it must synchronize with other processes that have access to that data. An
overview of synchronization issues is presented in “Overview of Synchronization Issues”
on page 17-12.
Note that a device driver that supports multithreaded applications must be aware that all
memory is shared by all lightweight processes; therefore, there are no data that are private
from the other lightweight processes in the process.