Figure 2.17 illustrates a representative hardware configuration for a SCSI bus.
Figure 2.17 SCSI Bus Hardware Configuration
In Figure 2.17, the host bus adapter (HBA) for this bus is connected to a system DMA controller. However, Figure 2.17 shows only a partial set of the HBA's target controllers (TIDs for "target identifier") and LUs where SCSI devices can be connected on the bus. Figure 2.17 also does not show the second SCSI bus that an HBA can drive.
Figure 2.18 illustrates the corresponding layered drivers for a representative set of SCSI devices.
Figure 2.18 SCSI Device Driver Layers
The NT SCSI port driver, implemented as a dynamic-link library, exports a set of support routines for use by one or more HBA-specific miniport drivers, depending on how many SCSI HBAs a given Windows NT machine has. HBA-specific miniport drivers that call only the ScsiPortXxx routines can link their binaries against either the NT SCSI port driver or the corresponding driver on other Microsoft operating systems that support Win32 applications. In other words, such HBA miniport drivers can be operating-system-independent because Microsoft operating systems will manage all OS-dependent requirements on their behalf.
The NT SCSI port driver also defines an interface to all NT SCSI (class) device drivers, including the system-supplied disk, tape, and CD-ROM class drivers. This port/class interface insulates every NT SCSI class driver from having to know anything about the HBAs driving buses on which their respective devices are connected. In other words, the NT SCSI port driver makes SCSI devices physically portable to any SCSI bus in a Windows NT system without changing the code in their corresponding class drivers.
Like the "AT" disk driver described in Section 2.4.4.1, the system-supplied SCSI disk class driver shown in Figure 2.18 supports any NT file system with a partition on one of its disk(s).
A subsystem-level utility can send system-defined device I/O control requests through the NT RAW file system down to the system SCSI tape class driver. As Figure 2.18 shows, NT tape class drivers have two parts:
1.A generic tape class driver that performs functions common to all tape drivers, such as creating device objects and sending IRPs to the NT SCSI port driver. The tape class driver is supplied by the system and is OS-dependent.
2.One or more device-specific tape miniclass drivers that are linked to the generic tape class driver. Tape miniclass drivers are portable across Microsoft operating systems that support Win32 applications. Each miniclass driver supports one more more tape devices.
Driver writers for SCSI tape devices implement only a tape miniclass driver.
The NT CDFS (CD-ROM file system) is layered over the system SCSI CD-ROM class driver.
If a new type (toaster) of SCSI device is added to the system, its driver must be an NT SCSI class driver. Developers of SCSI class drivers use the NT SCSI class/port interface for their devices, whether they write a class driver for a new type of SCSI peripheral device, write a new class driver for a type of device that already has a system class driver, or replace an existing class driver. However, it is usually unnecessary to write a new SCSI class driver if a system class driver for the same type of device already exists.
The system-supplied NT SCSI drivers assume compliance with the ANSI SCSI-II standard; in particular, compliance with the common command set incorporated by this standard. The SCSI disk filter driver, tape miniclass driver, and CD-ROM filter driver, shown in Figure 2.18, indicate where new SCSI device drivers can be inserted into each chain if the following conditions hold for the device:
·The device requires SCSI CDBs (command descriptor blocks) in a format different from the SCSI-II CDB format.
·The device requires some other nonstandard interface.
·The device has certain features that other devices of its type do not support.
For such a device, there are two alternatives:
1.For most kinds of SCSI devices, a vendor-specific SFD can attach itself above the system-supplied class driver, as shown in Figure 2.18, to intercept requests for its device and to translate requests to and completion data from the device as necessary. For SCSI tape devices, a vendor-specific tape miniclass driver can link itself to the system-supplied tape class driver to set up CDBs for its device.
2.Otherwise, a vendor-specific class driver can be added to the set of class drivers layered over the NT port driver like the toaster class driver shown in Figure 2.18. Note that implementing an NT SCSI class driver for a single device is far more work than writing an SFD or tape miniclass driver.
As Figure 2.18 shows, other value-added drivers can be inserted above any SCSI class or filter driver. For example a fault-tolerant disk driver might be inserted above the NT SCSI disk class driver (and filter driver, if any) to handle disk mirroring or duplexing. Such a value-added driver can ignore the NT class/port interface. However, such a higher-level driver must supply Dispatch entry points for each IRP_MJ_XXX that any NT device driver for the underlying peripheral device must handle, as already mentioned in Section 2.2.
See the Kernel-Mode Driver Reference for more information about the following:
·The requests that SCSI class, SFD, and tape miniclass drivers for particular types of devices are required to handle
·The ScsiPortXxx routines that HBA-specific SCSI miniport drivers call
·The standard functions for SCSI miniport drivers
·The system-defined structures for the SCSI class/port and port/miniport interfaces
See also Appendix A for more information about requirements for SCSI class, filter, tape miniclass, and miniport drivers.