Specifications

6
Writing a Start-I/O Routine
A driver start-I/O routine activates a device and then waits for a device interrupt
or timeout. This chapter describes the start-I/O routine. Chapter 8 describes
the reactivation of the driver routine that performs device-dependent I/O
postprocessing. With a few exceptions, the start-I/O routine discussed in the
following sections describes a direct-memory-access (DMA) transfer using a
single-unit controller.
6.1 Transferring Control to the Start-I/O Routine
The start-I/O routine of a device driver gains control from either of two system
routines: EXE_STD$QIODRVPKT or IOC_STD$REQCOM.
When FDT processing is complete for an I/O request, the FDT routine transfers
control to EXE_STD$QIODRVPKT, which, in turn, calls EXE_STD$INSIOQ.
If the designated device is idle, EXE_STD$INSIOQ calls IOC_STD$INITIATE
to create a driver fork process. The driver fork process then gains control in
the start-I/O routine of the appropriate driver. If the device is busy, EXE_
STD$INSIOQ queues the packet to the device unit’s pending-I/O queue.
After a device completes an I/O operation, the driver fork process exits by
transferring control to IOC_STD$REQCOM. IOC_STD$REQCOM inserts the I/O
request packet (IRP) for the finished transfer into the postprocessing queue. It
then dequeues the next IRP from the device unit’s pending-I/O queue and calls
IOC_STD$INITIATE to initiate the processing of this I/O request in the driver’s
fork process at the entry point of the driver’s start-I/O routine.
6.2 Context of a Driver Fork Process
A start-I/O routine does not run in the context of a user process. Rather, it has
the following context:
System context Driver code can only refer to system virtual addresses.
Kernel mode Execution occurs in the most privileged access mode and can,
therefore, change IPL and obtain spinlocks.
High IPL The system routine that creates a driver fork process obtains
the driver’s fork lock, raising IPL to driver fork level before
activating the driver.
Kernel stack Execution occurs on the kernel stack. The driver must not
alter the state of the stack without restoring the stack to its
previous state before relinquishing control.
In addition to the context described, the system packet-queuing routines set up
R3 and R5 for a driver start-I/O routine, as follows:
• R3 contains the address of the IRP.
• R5 contains the address of the unit control block (UCB) for the device.
6–1