Specifications

Writing an Interrupt Service Routine
7.1 Servicing a Solicited Interrupt
A driver’s interrupt service routine performs the following tasks to process the
interrupt and transfer control to the waiting driver:
1. Obtains the address of the device’s UCB from the IDB, as follows:
4(AP) CRB IDB IDB$L_OWNER UCB
The interrupt service routine restores the UCB address to R5.
2. Issues the DEVICELOCK macro to obtain synchronized access to device
registers.
3. Tests the interrupt-expected bit in the UCB status longword (UCB$V_INT in
UCB$L_STS). If the bit is set, the driver is waiting for an interrupt from this
device. After performing this test, the interrupt service routine must clear
UCB$V_INT to indicate that it has received the expected interrupt.
Note
Because device timeout processing mostly occurs at fork IPL (see
Section 8.2), a driver’s interrupt service routine, executing at device
IPL, could interrupt the processing of a timeout on the same device
unit. For this reason, the driver’s interrupt service routine should check
the interrupt-expected bit (UCB$V_INT) before handling the interrupt.
The operating system clears this bit before it calls the driver’s timeout
handler.
4. Obtains device-status or controller-status information from the device
registers, if necessary, and stores the status information in the UCB.
5. Places the contents of UCB$Q_FR3 and UCB$Q_FR4 in R3 and R4,
respectively.
6. Issues a JSB instruction to the waiting driver’s PC address, which is saved in
the UCB fork block at UCB$L_FPC.
The restored driver should execute as briefly as possible in interrupt context.
As soon as possible, the driver should invoke the IOFORK macro to request the
creation of a fork process at the driver’s fork IPL in order to complete the I/O
operation. Forking lowers the IPL of driver execution below device IPL, allowing
the processor to service additional device interrupts. IOFORK calls the routine
EXESTD$PRIMITIVE_FORK. EXESTD$PRIMITIVE_FORK inserts into the
appropriate fork queue the UCB fork block that describes the driver process. It
then returns control to the driver’s interrupt service routine. (See Section 8.1.1
for additional information on driver forking.)
The interrupt service routine then performs the following steps:
1. Removes the IDB pointer from the stack
2. Issues the DEVICEUNLOCK macro to release ownership of the device lock
3. Restores R0 through R5
4. Returns to the interrupt dispatcher via a RET instruction
5. The interrupt dispatcher dismisses the interrupt
7–2