Specifications

Developing a Device Drive
r
10-25
When a process blocked by SLEEP_LOCK_SIG is interrupted by a job control stop signal
and is subsequently continued, the SLEEP_LOCK_SIG routine transparently retries the
lock (the call cannot return without the lock). If the lock is acquired, SLEEP_LOCK_SIG
returns TRUE. When the process is interrupted by another type of signal, or a stop signal
for which a non-default disposition has been specified, SLEEP_LOCK_SIG returns
FALSE. Procedures for coding the device driver to handle premature returns from these
routines are explained in the section that follows.
A driver might have set some state as part of the execution of the I/O call before the pro-
cess was blocked. Because receipt of a signal requires a premature return out of the device
driver directly to the user, it might be necessary to clean up the device driver state before
returning to the user. The device driver, for example, might have locked some data struc-
tures that must be unlocked before returning to the user. The clean up must be accom-
plished by the driver. The driver must ensure that the process exits the kernel in an orderly
fashion.
Blocking Primitives and Premature Returns 10
When you use the blocking primitives SV_WAIT_SIG or SLEEP_LOCK_SIG, you must
be prepared for premature returns. An SV_WAIT_SIG or SLEEP_LOCK_SIG call does
not reliably block a process. To completely eliminate premature unblocking on a multipro-
cessor system, these routines would have to be very inefficient. Therefore, the driver
should always set a flag indicating the condition that is causing the process to block.
Prior to invoking the SV_SIGNAL, SV_BROADCAST,orSLEEP_UNLOCK routines which
unblock the process, the device driver must ensure that the flag has been cleared. When the
process becomes unblocked, the driver must also check the flag to be sure that the process
is unblocked for the correct reason.
The device driver for the SYSTECH High Performance Serial (HPS) controller illustrates
use of such a flag. The HPS and its associated driver provide access to serial devices
(CRTs, TTY devices, and so on) and parallel printers. Additional information on the HPS
is provided in the hps(7) system manual page.
Communications between the HPS controller and the driver are accommodated by use of
I/O control blocks, or IOCBs. An IOCB is a software structure that is used to pass I/O
requests to the board from the host software. The driver uses an IOCB state flag to coordi-
nate base-level I/O activity with interrupt-level activity. At base level, the driver sets the
flag to IOCB_NEEDS_SV_SIGNAL to indicate that it is going to block the process; it then
queues the I/O request to the controller and calls SV_WAIT_SIG to wait for completion of
the request:
. . .
dl->iocb_state = IOCB_NEEDS_SV_SIGNAL;
hps_queue_iocb(hp, dl);
. . .
SV_WAIT_SIG(hp->hps_syncvar, TTIPRI, hp->hps_lkp);
. . .
In the interrupt routine, where the driver handles the occurrence of an IOCB completion
interrupt, the driver checks the state flag to determine whether or not a process is sleeping