This section frequently refers to both device driver and adapter device driver. These two distinct device drivers work together in a layered approach to support attachment of a range of devices. The adapter device driver is the lower device driver of the pair, and the device driver is the upper device driver.
The adapter device driver is the software interface to the system hardware. This hardware includes the transport layer hardware, plus any other system I/O hardware required to run an I/O request. The adapter device driver hides the details of the I/O hardware from the device driver. The design of the software interface allows a user with limited knowledge of the system hardware to write the upper device driver.
The adapter device driver manages the transport layer but not the devices. It can send and receive commands, but it cannot interpret the contents of the command. The lower driver also provides recovery and logging for errors related to the transport layer and system I/O hardware. Management of the device specifics is left to the device driver. The interface of the two drivers allows the upper driver to communicate with different transport layer adapters without requiring special code paths for each adapter.
The device driver provides the rest of the operating system with the software interface to a given device or device class. The upper layer recognizes which commands are required to control a particular device or device class. The device driver builds I/O requests containing device commands, and sends them to the adapter device driver in the sequence needed to operate the device successfully. The device driver cannot manage adapter resources or give the command to the adapter. Specifics about the adapter and system hardware are left to the lower layer.
The device driver also provides recovery and logging for errors related to the device that it controls.
The operating system provides several kernel services allowing the device driver to communicate with adapter device driver entry points without having the actual name or address of those entry points. See Logical File System Kernel Services for more information.
When two devices communicate, one assumes the initiator-mode role, and the other assumes the target-mode role. The initiator-mode device generates the command, which requests an operation, and the target-mode device receives the command and acts. It is possible for a device to perform both roles simultaneously.
When writing a new adapter device driver, the writer must know which mode or modes must be supported to meet the requirements of the adapter and any interfaced device drivers.
The interface between the device driver and the adapter device driver for initiator-mode support (that is, the attached device acts as a target) is accessed through calls to the adapter device driver open, close, ioctl, and strategy subroutines. I/O requests are queued to the adapter device driver through calls to its strategy entry point.
Communication between the device driver and the adapter device driver for a particular initiator I/O request is made through the scsi_buf structure, which is passed to and from the strategy subroutine in the same way a standard driver uses a struct buf structure.