Specifications

Writing an Interrupt Service Routine
7.2 Servicing an Unsolicited Interrupt
7.2 Servicing an Unsolicited Interrupt
A device requests an interrupt to indicate to a driver that the device has changed
status. If a driver’s fork process starts an I/O operation on a device, the driver
expects to receive an interrupt from the device when the I/O operation completes
or an error occurs.
Other changes in the device’s status occur when the device has not been activated
by a device driver. The device reports such a change by requesting an unsolicited
interrupt. For example, when a user types on a terminal, the terminal requests
an interrupt that is handled by the terminal driver. If the terminal is not
attached to a process, the terminal driver causes the login procedure to be
invoked for the user at the terminal.
As another example, an unsolicited interrupt occurs whenever a disk drive goes
off line, as could happen when an operator spins it down or pushes the offline
button. The disk driver services the interrupt by altering volume and unit status
bits in the disk device’s UCB.
Devices request unsolicited interrupts because some external event has changed
the status of the device. A device driver can handle these interrupts in two ways:
• Ignore the interrupt as spurious
• Examine the device registers and take action according to their indications of
changed status, and then poll for any other changes in device status
As mentioned in Section 7.1, an interrupt service routine first obtains the address
of the device’s UCB from the IDB. It then issues the DEVICELOCK macro to
obtain synchronized access to device registers.
The routine determines whether an interrupt is solicited or not by examining the
interrupt-expected bit in the UCB status longword (UCB$V_INT in UCB$L_STS).
If the driver decides to handle the unsolicited interrupt, it must observe certain
precautions. Certain methods of servicing unsolicited interrupts—for instance
sending a message to the operator or the job controller’s mailbox—must be
accomplished at an IPL lower than device IPL. Although the interrupt service
routine can legitimately fork to accommodate unsolicited interrupts, it should
exercise extreme caution in doing so.
If UCB$V_BSY is set in UCB$L_STS, the UCB fork block is currently in use
by the driver’s start-I/O routine. An attempt by the interrupt service routine to
concurrently use the fork block can destroy the fork context already stored in that
UCB. Moreover, if UCB$V_BSY is not set, the interrupt service routine cannot
safely assume that the fork block is not in use, for it may be currently employed
to service a previous unsolicited interrupt.
To avoid confusion, code servicing an unsolicited interrupt must ensure that the
fork block it requires is not being used. Perhaps the safest method to guarantee
this is for the driver to define a separate fork block in a device-specific UCB
extension. The driver should also define a semaphore bit to control access to
this fork block and protect against multiple forking. Note that the driver should
access the semaphore bit using interlocked instructions (for example, BBSSI or
BBCCI).
If, upon servicing an unsolicited interrupt, the driver’s interrupt service routine
examines the semaphore and discovers that a fork is already in progress (that is,
the bit is set), it should not attempt to fork.
7–3