Specifications

Introduction
1.3 I/O Database
When a process issues the Assign I/O Channel ($ASSIGN) system service, the
system writes a description of the assigned device to the CCB.
Unlike the data structures mentioned earlier, a CCB is not located in nonpaged
system space, but in the process’s control region (P1 space).
1.3.3 I/O Request Packets
The third part of the I/O database is a set of I/O request packets. When a process
requests I/O activity, the operating system constructs an I/O request packet
(IRP), that describes the I/O request in a standard form.
The IRP contains fields into which the system and driver I/O preprocessing
routines can write information: for instance, the device-dependent arguments
specified in the call to the $QIO system service. The packet also includes buffer
addresses, a pointer to the target device’s UCB, an I/O function code, and
pointers to the I/O database. After preprocessing, the IRP can be queued to a list
originating in the device’s UCB to await processing by the driver.
When the device unit is free and the IRP is next in line to be processed on the
unit, the system sends it to the device driver’s start-I/O routine. The start-I/O
routine uses the IRP as its source of detailed instructions about the operation to
be performed.
1.4 Synchronization of Driver Activity
Device drivers and other kernel-mode code must maintain synchronization with
other priority operating system activities. The term synchronization refers to
the means by which such code accesses shared data in a consistent, orderly, and
predictable fashion. Because there may be more than one processor active in an
OpenVMS AXP system, system-level code must synchronize its actions with other
code threads it may have preempted on the same (or local) processor, as well as
with those that are active (or to be activated) on other processors in the system.
The operating system uses hardware and software interrupt priority levels (IPLs)
to order system events on each local processor in an OpenVMS AXP system.
AXP hardware defines 32 interrupt priority levels (IPLs). The higher numbered
IPLs (16 to 31) are reserved for hardware interrupts, such as those posted by
devices. The operating system uses the lower numbered IPLs (0 to 15). Code that
executes at a higher IPL takes precedence over code that executes at a lower IPL.
A driver, in concert with the operating system, ensures that it maintains system
synchronization by performing certain activities and by accessing certain data
only at the appropriate IPL. In a multiprocessing system, the driver extends
the synchronization it achieves by executing locally at a given IPL by acquiring
ownership of the spinlock associated with the operation it is performing.
1.5 Driver Context
As indicated in Section 1.2.2, a driver may have several routines to which
the operating system may pass control in certain situations. The context in
which any one routine receives control from the operating system may differ
substantially from that in which another receives control. It is essential that a
driver routine not attempt to exceed the limitations of the context in which it
executes.
logical channel (the channel argument to the $ASSIGN and $QIO system services) in
accomplishing I/O operations.
1–6