Specifications

8
Completing an I/O Request and Handling
Timeouts
Once a driver has activated the device and invoked the wait-for-interrupt macro,
the driver remains suspended until the device requests an interrupt or times out.
If the device requests an interrupt, the driver’s interrupt service routine handles
the interrupt and then reactivates the driver at the instruction following the
wait-for-interrupt macro. The reactivated driver performs device-dependent I/O
postprocessing.
If the device does not request an interrupt within the designated time interval,
the system transfers control to the driver’s timeout handling routine. The
address of the timeout handling routine is specified as the excpt argument to the
wait-for-interrupt macro.
8.1 I/O Postprocessing
Once the driver interrupt service routine has processed an interrupt, it transfers
control to the driver by issuing a CALL instruction. At this point, the driver
is executing in interrupt context. If the driver were to continue executing in
interrupt context, it would lock out most other processing on the processor
including the handling of hardware interrupts.
To restore the driver to the context of a driver fork process, the driver invokes the
system macro IOFORK. Once the fork process has been created and dispatched
for execution, it executes the driver code that completes the processing of the I/O
request.
8.1.1 EXE_STD$PRIMITIVE_FORK
IOFORK generates a call to the routine EXE_STD$PRIMITIVE_FORK. EXE_
STD$PRIMITIVE_FORK converts the driver context from that of an interrupt
service routine to that of a fork process by performing the following steps:
1. It disables software timeouts by clearing the timeout enable bit in the UCB
status longword (UCB$V_TIM in UCB$L_STS).
2. It saves R3 and R4 of the current driver context in the UCB fork block
(UCB$L_FR3 and UCB$L_FR4).
3. It obtains the fork lock index of the driver from the UCB (UCB$B_FLCK) and
uses it to determine in which fork queue it should place the fork block.
4. It inserts the address of the UCB fork block (R5) into the processor-specific
fork queue corresponding to the driver’s fork IPL.
5. Finally, if the fork block is the first entry in the fork queue, EXE_
STD$PRIMITIVE_FORK requests a software interrupt from the local
processor at the driver’s fork IPL.
8–1