Specifications

Writing a Start-I/O Routine
6.2 Context of a Driver Fork Process
The start-I/O routine must preserve all general registers except R0, R1, R2, and
R4.
Before the packet-queuing routines call the start-I/O routine, they copy the
following IRP fields into their corresponding slots in the device’s UCB:
• IRP$L_BCNT UCB$_BCNT
• IRP$_BOFF
UCB$_BOFF
• IRP$L_SVAPTE
UCB$L_SVAPTE
6.3 Functions of a Start-I/O Routine
The processing performed by a start-I/O routine is device specific. A start-I/O
routine normally contains elements that perform the following functions to
activate:
• Analyzing the I/O function
• Transferring the details of a request from the IRP into the UCB
• Obtaining and initializing the controller
• Modifying device registers to activate the device
A start-I/O routine of a DMA device driver performs additional tasks to prepare
the device for a DMA transfer prior to activating the device. These tasks include
the following:
• Obtaining I/O adapter resources such as map registers
• Computing the starting address of a data transfer
The following sections describe the general activities of a start-I/O routine for a
typical device. The details of DMA processing are specific to the particular device.
For more information, see the appropriate bus support chapter in this manual.
6.3.1 Obtaining Controller Access
If the device is one of several attached to a controller, the start-I/O routine
invokes the system macro REQCHAN to assign the controller’s data channel to
the device unit. Controllers that control only one device do not require arbitration
for the controller’s data channel. REQCHAN calls the system routine IOC_
STD$PRIMITIVE_REQCHANL that acquires ownership of the controller data
channel.
The transfer being controlled by the start-I/O routine discussed here requires no
seek preceding the transfer. Disk I/O is an example of a transfer that requires a
seek first. To permit seeks to be overlapped with transfers, invoke REQPCHAN
with the argument pri=HIGH. Specifying pri=HIGH inserts a request for a
channel at the head of the channel wait queue.
If the channel is not available, IOC_STD$PRIMITIVE_REQCHANL suspends
driver processing by saving the driver’s context in the UCB fork block and
inserting the fork block in the channel wait queue. IOC_STD$PRIMITIVE_
REQCHANL then returns control to the caller of the driver, that is, to EXE_
STD$INSIOQ.
Note that, because IOC_STD$RELCHAN moves the address of the IDB into R4
before resuming a suspended driver, IOC_STD$PRIMITIVE_REQCHANL does
not save R4 in the UCB fork block.
6–2