Specifications

Writing a Start-I/O Routine
6.3 Functions of a Start-I/O Routine
If the bit is set, a power failure might have occurred between the time that the
start-I/O routine wrote the first device register and the time that the start-I/O
routine is ready to activate the device. Such a power failure could modify the
already-written device registers and cause unpredictable device behavior if the
device were to be started.
If the bit UCB$V_POWER is set, the start-I/O routine branches to an error
handler in the driver. The driver error handler must perform the following
actions:
• Clear UCB$V_POWER
• Issue the DEVICEUNLOCK macro to release the device lock and restore IPL
to fork IPL
After performing these tasks, many drivers transfer control to the beginning of
the start-I/O routine, which restarts the processing of the I/O request.
6.3.6 Activating the Device
If no power failure has occurred, the start-I/O routine copies the contents of the
control mask into the device’s CSR. When the device notices the new contents of
the device register, it begins to transfer the requested data.
6.4 Waiting for an Interrupt or Timeout
Once the start-I/O routine activates the device, the driver fork process cannot
proceed until one of these events occurs:
• The device generates a hardware interrupt.
• The device does not generate a hardware interrupt within an expected time
limit, which is to say that a device timeout occurs.
Still executing at IPL$_POWER, the driver’s start-I/O routine asks the operating
system to suspend the driver fork process by invoking one of the following macros:
WFIKPCH Wait for an interrupt or timeout and keep the controller data channel
WFIRLCH Wait for an interrupt or timeout and release the controller data
channel
The WFIKPCH and WFIRLCH macros require the address of a timeout handling
routine in the excpt argument. Optionally, but almost always, the driver can also
indicate the number of seconds the system must wait before signaling a timeout
in the time argument. For more information, see OpenVMS AXP Device Support:
Reference.
Both macros invoke routines that release ownership of the device lock, relinquish
synchronization, and return IPL to the previous level when exiting. These
routines expect to find the return IPL on the stack. This IPL is saved on the
stack by the DEVICELOCK macro as described in Section 6.3.4.
Drivers generally keep the controller data channel while waiting for the interrupt
or timeout. Drivers of devices with dedicated controllers always keep the channel
because only one unit ever needs it. For devices that share a controller, some
operations, such as disk seeks, do not require the controller once the operation
has begun. In such cases, the driver can release the controller’s data channel
while waiting for an interrupt or timeout so that other units on the controller can
start their operations.
6–4