VAX/VMS Device Driver I/O Sequence

This document, a training module from Digital Equipment Corporation, outlines the detailed Input/Output (I/O) sequence within the VAX/VMS operating system, emphasizing the collaborative interaction between system and device driver routines. It aims to elucidate the control flow and specific events involved in a typical I/O operation, covering key routines and data structures.

The I/O process typically begins when a user issues a $QIO system service request. This request is dispatched to the $QIO Processor (EXE$QIO), which validates the request, creates an I/O Request Packet (IRP), and invokes Function Decision Table (FDT) routines. FDT routines perform device-specific tasks, manage buffer allocation (for direct or buffered I/O), and initiate the Driver Start I/O Routine or queue the IRP if the device is busy. This initial phase occurs within the context of the requesting process.

The Driver Start I/O Routine then initializes the device hardware and waits for a device interrupt using the WFIKPCH macro. Upon an interrupt, the Driver Interrupt Service Routine identifies the interrupting unit, restores the driver's fork process context, reads device registers, and issues an IOFORK macro to lower the Interrupt Priority Level (IPL). The resumed driver fork process handles interrupt-specific actions, releases resources, and eventually calls the I/O Postprocessing Routine via the REQCOM macro.

I/O posting is managed by the VAX/VMS executive. The REQCOM macro causes the I/O status to be stored in the IRP, the IRP to be placed in the I/O post queue, and an IPL 4 software interrupt to be requested. The I/O Post Interrupt routine processes these queued IRPs, unlocking memory pages, deallocating buffers, and queuing a special kernel Asynchronous System Trap (AST). Finally, an AST Interrupt (at IPL 2) delivers this kernel AST, which returns I/O status and data to the user, potentially queues a user-specified AST, and deallocates the IRP.

The document also details interrupt dispatching mechanisms, which differ for UNIBUS and MASSBUS devices, and involve data structures like the System Control Block (SCB), Adapter Control Blocks (ADPs), Channel Request Blocks (CRBs), Interrupt Data Blocks (IDBs), and Unit Control Blocks (UCBs). Furthermore, it describes the roles of the Timeout Routine (for handling unresponsive devices), the Cancel I/O Routine (for aborting I/O requests), and Initialization Routines (which prepare controllers and units during system boot, power failure recovery, or driver loading).