The
operating system employs a class/port driver architecture to communicate
with devices on the SCSI bus. The class/port design allows the responsibilities
for communication between the operating system and the device to
be cleanly divided between two separate driver modules (see
OpenVMS SCSI Class/Port Interface).
Figure 1 OpenVMS SCSI Class/Port Interface
The SCSI
port driver transmits and receives SCSI commands and
data. It knows the details of transmitting data from the local processor's
SCSI port hardware across the SCSI bus. Although it understands
SCSI bus phases, protocol, and timing, it has no knowledge of which
SCSI commands the device supports, what status messages it returns,
or the format of the packets in which this information is delivered.
Strictly speaking, the port driver is a communications path. When
directed by a SCSI class driver, the port driver forwards commands
and data from the class driver onto the SCSI bus to the device.
On any given OpenVMS system, a single SCSI port driver handles bus-level
communications for all SCSI class drivers that may exist on the system.
The SCSI
class driver acts as an interface between the user and
the SCSI port, translating an I/O function as specified in a user's
$QIO request to a SCSI command targeted to a device on the SCSI
bus. Although the class driver knows about SCSI command descriptor
buffers, status codes, and data, it has no knowledge of underlying
bus protocols or hardware, command transmission, bus phases, timing,
or messages. A single class driver can run on any given OpenVMS
system, in conjunction with the SCSI port driver that supports that system.
The operating system supplies a standard SCSI disk class driver
and a standard SCSI tape class driver to support its disk and tape
SCSI devices.