Specifications

D
evice Driver Programming
17-38
and the Secure/PowerUX kernels, the exception-handling code checks for
interrupt-handling routines.
• An interrupt-handling routine can make only two system calls:
server_wake1(2) and server_wakevec(2). These calls enable
the calling process to wake one or more processes that are blocked in the
server_block(2) system call (see “The Server System Calls” on page
17-21 for a description of these calls). Certain limitations apply to an
interrupt-handling routine’s use of these calls.
• An interrupt-handling routine can call other routines, but it must eventually
exit via an explicit or implicit return from inside the routine whose address
is specified in the ic_routine field of the icon_conn structure
supplied on the iconnect(3C) library routine call.
• Because the interrupt-handling routine executes at interrupt level, you
cannot use such user-level debuggers as adb, dbx, and gdb to debug it;
however, you can use the console processor to obtain some debugging
capability for this routine. Guidelines for debugging the interrupt-handling
routine are provided in the PowerUX Real-Time Guide.
If you use the server_wake1(2) or the server_wakevec(2) system call in the
user-level driver’s interrupt-handling routine to wake a process that is blocked in the
server_block(2) system call, you must ensure that the interrupt-handling routine
and the routine that calls server_block synchronize execution through the use of some
element of shared data. If, for example, the driver’s interrupt-handling routine services I/O
completion interrupts, a process that wants to wait for completion of an I/O operation can
check a flag that indicates whether or not the operation has been completed. If it finds that
the flag has not been set, it blocks until the operation has been completed. When an I/O
completion interrupt occurs, the interrupt-handling routine sets the flag and wakes the
waiting process. The server system calls are described in “Understanding Operating
System Support for a User-Level Driver” on page 17-15. Procedures for using them are
explained in detail in the PowerUX Real-Time Guide. Example programs that illustrate
their use are provided.
Developing the Device Configuration Program 17
User-level device drivers written by Concurrent Computer Corporation personnel must
provide a configuration program for the device that is controlled by the user-level driver.
This program is to be invoked from the system’s /etc/rc2.d and /etc/dinit.d
scripts. (See the rc2(1M) and dinit(1M) system manual pages for details.) The
purpose of a configuration program is to provide device driver initialization at system boot
time. A configuration program can also provide some basic utility functions that are help-
ful to users. Such functions include reset and debug.
The device configuration program has a set of standard options. The functions associated
with each option are described as follows:
-c create the shared memory regions required by the driver, and initialize the
device
-r reset the device