Specifications

Completing an I/O Request and Handling Timeouts
8.1 I/O Postprocessing
The steps listed previously move the fork process context into the UCB’s fork
block. They save R3 through R5 and the driver’s PC address. The driver’s fork
process resumes processing when the system fork dispatcher dequeues the UCB
fork block from the fork queue, and reactivates the driver at the driver’s fork IPL.
8.1.2 Completing an I/O Request
When the operating system reactivates a driver’s fork process by dequeuing
the fork block, the driver resumes processing of the I/O operation holding the
appropriate fork lock at fork IPL.
1. Releases map registers
2. Releases the controller (applies only to drivers of devices on multiunit
controllers)
3. Checks device register images saved in the UCB to determine the status of
the I/O operation
4. Saves in the I/O reuest packet (IRP) the status code, transfer count, and
device-dependent status that is to be returned to the user process in an I/O
status block (IOSB)
5. Returns control to the operating system
8.1.2.1 Releasing the Controller
To release the controller channel, the driver code invokes the system macro
RELCHAN. RELCHAN calls the system routine IOC_STD$RELCHAN. If another
driver is waiting for the controller channel, IOC_STD$RELCHAN grants that
driver’s fork process the channel, restores its context from the UCB fork block,
and transfers control to the saved PC. When no more drivers are awaiting the
channel, IOC_STD$RELCHAN returns control to the fork process that released
the channel.
Drivers for devices with dedicated controllers need not release the controller’s
data channel. By means of code in the unit initialization routine, these drivers
set up the device’s UCB so that the device owns the controller permanently.
Drivers must be executing at driver’s fork IPL when they invoke RELCHAN or
call IOC_STD$RELCHAN.
8.1.2.2 Saving Status, Count, and Device-Dependent Status
To save the status code, transfer count, and device-dependent status, the driver
performs the following steps:
1. Loads a success status code (SS$_NORMAL), or whatever is appropriate, into
bits 0 through 15 of R0.
2. Loads the number of bytes transferred into the high-order 16 bits of R0 (bits
16 through 31), if the I/O operation performed by the device is a transfer
function.
3. Loads device-dependent status information, if any, into R1.
1
1
R0 and R1 are the status values that the operating system returns to the user process
in the I/O status block specified in the original $QIO system service.
8–2