Table of Contents
There are too many SCSI low level drivers to detail in this document. As an alternative to giving any superficial overview here, the reader is given suggestions of places to look for further information.
The source directory for the SCSI subsystem in the Linux kernel is a good place to start: /usr/src/linux/drivers/scsi. Several drivers have information in a "readme" file: README.<driver_name> . Others have extensive information at the top of their ".c" file This information often includes a version number, change logs and kernel boot time and module load time options. Often the latter information can be found in the installation guides of the various Linux distributions. Sometimes the driver maintainer will have a web site containing the most recent bug fix information. Official maintainers are listed in the /usr/src/linux/MAINTAINERS file. If there is nothing there, look in the relevant ".c" file in the SCSI subsystem directory. Some old drivers have no active maintainers. In such cases posting to the linux-scsi newsgroup may help [see N1 ].
For an overview of the drivers supplied with the kernel source tree, use one of the kernel configuration programs (e.g. cd /usr/src/linux; make menuconfig). The help information associated with each selection can be found together in one (large) flat file at /usr/src/linux/Documentation/Configure.help. Drivers can be obtained from other places. It is unlikely that a SCSI driver made for the lk 2.2 series (or before) will build or operate successfully in the lk 2.4 series. [From a programmatic viewpoint there are not a lot of things that need changing.] Drivers may even be only available in binary form, in which case make sure that you trust the provider and follow their instructions closely.
Lower level drivers can support either of 2 error handling strategies. The older one is considered obsolete while the newer one is often called "new_eh". The advantage of "new_eh" is that it uses a separate kernel thread per host (named "scsi_eh_<n>" where <n> is the host number) to facilitate error recovery. Both error handling strategies were also available in the lk 2.2 series in which very few adapter drivers used "new_eh". In the lk 2.4 series, more drivers are using it and the plan for the forthcoming lk 2.5 development series is to drop mid level support for the older, obsolete error strategy.
Drew Eckhardt's SCSI-HOWTO document [see reference W7 ] goes into much more detail about lower level (adapter) drivers than this document. Since that SCSI-HOWTO is 5 years old, many things have changed and more drivers have been added.
There is a lower level driver called scsi_debug that simulates one or more "direct access" devices (i.e. disk(s)) using the computer's memory. From lk 2.4.17 it acts as a "ram disk". While there are many ram disk implementations available in Linux (e.g. ramfs), scsi_debug may help to isolate a defective scsi driver in a problematic installation. See scsi_debug.c for further information.
SCSI can be viewed as a command set and a set of hardware buses that convey that command set. Those hardware buses can be further divided into those used exclusively for SCSI (e.g. ultra wide), those shared with other protocols (e.g. USB, IEEE 1394) and those buses not defined by the various SCSI standards. In the final category there are several interesting examples including ATAPI CD writers and PC parallel bus ZIP drives. Such devices use the SCSI command set (or something very close to it) over a foreign bus.
This section briefly outlines various pseudo lower level drivers which essentially communicate with other Linux subsystems in order to send the SCSI command set to devices controlled by those other subsystems. This raises some ownership issues that often confuse users and result in many questions to the maintainers.
IDE-SCSI. From configuration point of view, ide-scsi will grab and try to control every ATA (a.k.a. IDE) device which doesn't have a "native" driver attached (such as ide-cd, ide-tape, etc). So for example, if both ide-cd and ide-scsi are compiled into the kernel in a system which has an ATAPI cdrom, ide-cd will get to control it. If only ide-scsi is compiled in, it will get the device. There are some kernel boot time parameters to control which driver gets which device.
The preferences of the IDE subsystem can be overridden with one of these kernel boot time parameters (of which the first is most interesting for this subsystem):
hdx=ide-scsi
hdx=ide-cdrom
hdx=ide-floppy
[The term hdx is used to refer to one of the IDE/ATA devices in {hda, hdb, hdc ...}.] In the 2.4 series "hdx=scsi" was added but it is not very useful, see see the section called “ATAPI cdroms”.
When the driver is running, the device will be accessible using the SCSI device (/dev/sda, /dev/sr0 , etc), and not through the corresponding /dev/hdx device. Still, the /dev/hdx device will be available, but only for configuration.
All the generic IDE configuration parameters (DMA on/off, 32-bit I/O, unmasking irq's, etc) are available by using the /dev/hdx device, for example to enable DMA:
hdparm -d1 /dev/hdx
[13] Using cat /proc/ide/hdx/settings will show the available settings. All the generic IDE driver settings will be available there, as well as the following "ide-scsi specific" settings:
bios_cyl
bios_head
bios_sect
transform
log
The first three choose the virtual geometry that the drive will return to the sd driver, in case it's a disk drive (ZIP, etc). "transform" will configure/enable/disable the SCSI to ATAPI CDB transformation layer:
bit 0: Enable(1)/Disable(0) transformation for commands not originated from the sg driver.
bit 1: Enable/Disable transformation for commands issued using the sg driver.
"log" will log debugging information. This is useful also to debug user-space programs using the sg driver, as it will list the CDB traffic on the bus -- each issued command, along with its completion status. To enable/disable a specific settings, use something like:
echo "log:1" > /proc/ide/hdx/settings
To turn off the "using_dma" flag use:
echo "using_dma:0" > /proc/ide/hdx/settings
PPA + IMM. Iomega ZIP drives come in a variety of flavours including parallel port, SCSI, and ATAPI. The parallel port versions (both old and new) are driven by ppa and imm respectively.
The parallel port ZIP drives are actually SCSI devices which tunnel SCSI commands over the parallel port using interfaces called VPI0 (older-style) and VPI2 (newer-style). The ppa driver is the VPI0 host implementation and the imm driver is the VPI2 host implementation.
The way it works is that the HBA is a chip inside the ZIP drive, so that the host adapter and the peripheral are in the same actual case.
PPSCSI. The new, not-yet-integrated, architecture for devices that use SCSI over a parallel port cable is ppscsi. The ppscsi module provides the boiler plate code and makes it easy to write implementations for different interfaces.
Each ppscsi protocol module registers itself with the ppscsi module, passing in a list of entry points for the various things that are common to all protocol drivers.
The structure of the PPSCSI drivers.
The plan is that the ppscsi architecture will absorb both the ppa and imm drivers and protocol modules; only vpi0 has been written so far. See www.torque.net/parport/ppscsi.html.
USB. USB classifies a group of devices as "mass storage" (e.g. disks) and interacts with these using the SCSI command set. The module name is "usb-storage". See www.one-eyed-alien.net/~mdharm/linux-usb.
There is also the usb/microtek driver for controlling X6 USB scanners from Microtek. When configured, the SANE application uses the sg driver to send SCSI commands over USB to control this scanner.
I2O. See kernel source file /usr/src/linux/drivers/i2o/io2_scsi.c .
IEEE 1394. Support for IEEE 1394 devices that use the SBP-2 protocol is now available (lk 2.4.7). See the IEEE 1394 paragraph in this section for more information.
iSCSI. An IETF draft is taking shape for iSCSI. This sends the SCSI command set over a TCP network connection. iSCSI seems to be gaining popularity quickly and there are several implementations for Linux taking shape. One implementation is at sourceforge.net/projects/intel-iscsi/. Use your favourite search engine to find other projects.
[13] It has been reported that in some distributions the attempt to use the hdparm command fails. In this case use the "echo ... > /proc/ide/hdx/settings" form.