Chapter 1. Introduction

This document describes the SCSI subsystem as the Linux kernel enters the 2.4 production series.

An external view of the SCSI subsystem is the main theme. Material is included to help the system administration of the Linux SCSI subsystem. There are also brief descriptions of ioctl()s and interfaces that may be relevant to those writing applications that use this subsystem. However internal data structures and design issues are not addressed [see reference W2]. To unclutter the presentation, compile options and system calls (including ioctl()s) have been placed in Appendix E. Although not strictly part of the SCSI subsystem, there is also a description of raw devices in Chapter 11.

For those who have no interest in the SCSI subsystem and just want to get their ATAPI cd writer going, see Section 9.2.4. It may also be useful to browse Chapter 2.

This document follows on from one written five years ago by Drew Eckhardt called the SCSI-HOWTO [see reference W7]. That document described the SCSI subsystem in Linux kernel 1.2 and 1.3 series. It is still available from the Linux Documentation Project [LDP, see reference W8] in its "unmaintained" section. Both documents have roughly similar structures although Drew's document has a lot of information on the adapter drivers.

This document can be found in electronic form at www.tldp.org/HOWTO/SCSI-2.4-HOWTO. The home site and perhaps the most up to date version of this document can be found at www.torque.net/scsi/SCSI-2.4-HOWTO (this is the multi-page html version). At that location this document is rendered in txt, pdf, ps, a single (long) page of html as well as multi-page html. For example, a pdf version is at www.torque.net/scsi/SCSI-2.4-HOWTO.pdf).

This document was last altered on 24th August 2004.

Chapter 2. Architectural Overview

The SCSI subsystem has a 3 level architecture with the "upper" level being closest to the user/kernel interface while the "lower" level is closest to the hardware. The upper level drivers are commonly known by a terse two letter abbreviation (e.g. "sd" for SCSI disk driver). The names of the corresponding module drivers which, for historical reasons, sometimes differ from the built in driver names are shown in braces in the following diagram.

The upper level supports the user-kernel interface. In the case of sd and sr this is a block device interface while for st and sg this is a character device interface. Any operation using the SCSI subsystem (e.g. reading a sector from a disk) involves one driver at each of the 3 levels (e.g. sd, SCSI mid level and aic7xxx drivers).

As can be seen from the diagram, the SCSI mid level is common to all operations. The SCSI mid level defines internal interfaces and provides common services to the upper and lower level drivers. Ioctls provided by the mid level are available to the file descriptors belonging to any of the 4 upper level drivers.

The most common operation on a block device is to "mount" a file system. For a sd device typically a partition is mounted (e.g. mount -t ext2 /dev/sda6 /home). For a sr device usually the whole device is mounted (e.g. mount -t iso9660 /dev/sr0 /mnt/cdrom). The dd command can be used to read or write from block devices. In this case the block size argument ("bs") needs to be set to the block size of the device (e.g. 512 bytes for most disks) or an integral multiple of that device block size (e.g. 8192 bytes). A recent addition to the block subsystem allows a device (or partition) to be mounted more than once, at different mount points.

Sd is a member of the generic disk family, as is the hd device from the IDE subsystem. Apart from mounting sd devices, the fdisk command is available to view or modify a disk's partition table. Although the hdparm command is primarily intended for ATA disks (also known as IDE or EIDE disks), some options work on SCSI disks.

Sr is a member of the CD-ROM subsystem. Apart from mounting file systems (e.g. iso9660), audio CDs can also be read. The latter action does not involve mounting a file system but typically by invoking some ioctls. General purpose Linux commands such as dd cannot be used on audio CDs.

St is a char device for reading and writing tapes. Typically the mt command is used to perform data transfers and other control functions.

Sg is a SCSI command pass through device that uses a char device interface. General purpose Linux commands should not be used on sg devices. Applications such as SANE (for scanners), cdrecord and cdrdao (for cd writers) and cdparanoia (for reading audio CDs digitally) use sg.

Chapter 3. Names and Addresses

This section covers the various naming schemes that exist in Linux and the SCSI worlds and how they interact.

Chapter 4. Kernel Configuration

The Linux kernel configuration is usually found in the kernel source in the file: /usr/src/linux/.config . It is not recommended to edit this file directly but to use one of these configuration options:

• make config - starts a character based questions and answer session

• make menuconfig - starts a terminal-oriented configuration tool (using ncurses)

• make xconfig - starts a X based configuration tool

The descriptions of these selections that is displayed by the associated help button can be found in the flat ASCII file: /usr/src/linux/Documentation/Configure.help

Ultimately these configuration tools edit the .config file. An option will either indicate some driver is built into the kernel ("=y") or will be built as a module ("=m") or is not selected. The unselected state can either be indicated by a line starting with "#" (e.g. "# CONFIG_SCSI is not set") or by the absence of the relevant line from the .config file.

The 3 states of the main selection option for the SCSI subsystem (which actually selects the SCSI mid level driver) follow. Only one of these should appear in an actual .config file:

CONFIG_SCSI=y CONFIG_SCSI=m # CONFIG_SCSI is not set

Some other common SCSI configuration options are:

CONFIG_BLK_DEV_SD [disk (sd) driver] CONFIG_SD_EXTRA_DEVS [extra slots for disks added later] CONFIG_BLK_DEV_SR [SCSI cdrom (sr) driver] CONFIG_BLK_DEV_SR_VENDOR [allow vendor specific cdrom commands] CONFIG_SR_EXTRA_DEVS [extra slots for cdroms added later] CONFIG_CHR_DEV_ST [tape (st) driver] CONFIG_CHR_DEV_OSST [OnSteam tape (osst) driver] CONFIG_CHR_DEV_SG [SCSI generic (sg) driver] CONFIG_DEBUG_QUEUES [for debugging multiple queues] CONFIG_SCSI_MULTI_LUN [allow probes above lun 0] CONFIG_SCSI_CONSTANTS [symbolic decode of SCSI errors] CONFIG_SCSI_LOGGING [allow logging to be runtime selected] CONFIG_SCSI_<ll_driver> [numerous lower level adapter drivers] CONFIG_SCSI_DEBUG [lower level driver for debugging] CONFIG_SCSI_PPA [older parallel port zip drives] CONFIG_SCSI_IMM [newer parallel port zip drives] CONFIG_BLK_DEV_IDESCSI [ide-scsi pseudo adapter] CONFIG_I2O_SCSI [scsi command set over i2o bus] CONFIG_SCSI_PCMCIA [for SCSI HBAs on PCMCIA bus] CONFIG_USB_STORAGE [usb "mass storage" type] CONFIG_MAGIC_SYSRQ [Alt+SysRq+S for emergency sync] [Alt+SyrRq+U for emergency remount ro]

If the root file system is on a SCSI disk then it makes sense to build into the kernel the SCSI mid level, the sd driver and the host adapter driver that the disk is connected to. In most cases it is usually safe to build the sr, st and sg drivers as modules so that they are loaded as required. If a device like a scanner is on a separate adapter then its driver may well be built as a module. In this case, that adapter driver will need to be loaded before the scanner will be recognized.

Linux distributions have many of the SCSI subsystem drivers built as modules since building all of them in would lead to a very large kernel that would exceed the capabilities of the boot loader. This leads to a "chicken and the egg" problem in which the SCSI drivers are needed to load the root file system and vice versa. The 2 phase load used by the initrd device addresses this problem (see Chapter 6 for more details).

Chapter 5. Boot Parameters

On a PC the motherboard's BIOS together with the SCSI BIOS provided by most SCSI host adapters takes care of the problem of loading the boot loader's image from a SCSI disk into memory and executing it. This may require some settings to be changed in the motherboard's BIOS. When more than one SCSI adapter is involved, the SCSI BIOS settings may need to change to indicate which one contains the disk with the boot image. The boot image make also come from an ATA (IDE) disk, a bootable CD-ROM or a floppy.

Both lilo and grub are commonly used boot loaders with Linux. Their configuration files are in /etc/lilo.conf and /etc/grub.conf [3] respectively. One difference is that after changing lilo's configuration the lilo command must be executed for the changes to take effect (and there is no equivalent requirement for grub). See their "man" pages for usage information. An excellent paper on lilo and the Linux bootup sequence can be found ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz. For further information on grub see www.gnu.org/software/grub.

Some boot parameters related to the SCSI subsystem:

single [enter single user mode] <n> [enter run level <n> {0..6}] root=/dev/sda6 [*] root=/dev/scsi/host0/bus0/target0/lun0/part6 [*] root=/dev/sd/c0b0t0u0p6 [*] devfs=mount [overrides CONFIG_DEVFS_MOUNT=n] devfs=nomount [overrides CONFIG_DEVFS_MOUNT=y] init=<command> [executes <command> rather than init] quiet [reduce output to console during boot] debug [increase output to console during boot] nmi_watchdog=0 [turn off NMI watchdog on a SMP machine] max_scsi_luns=1 [limits SCSI bus scans to lun==0] scsi_allow_ghost_devices=<n>

* When devfs is in use the initial read-only mount of the root partition can be done via the old /dev/sd<a><n> notation or the new devfs notation (and two of these are shown). The joint "root=/dev/sda6 single" may be useful when disk or adapter changes have broken the kernel boot load.

The "root=" argument may also be a hex number. For example, if the root partition is on /dev/sda3 then "root=803" is appropriate. The last two digits are the minor device number discussed in an earlier section.

The default argument to the "init" parameter is /sbin/init (see man (8) init). If files such as /etc/fstab have incorrect entries, it may be useful to drop directly into a shell with "init=/bin/bash". However if shared libraries files or their paths are inappropriate this may also fail. That leaves "init=/sbin/sash" which is a statically linked shell with many useful commands (for repairing a system) built in (see man (8) sash).

When Linux fails to boot after reporting a message like:

VFS: Cannot open root device 08:02

then the kernel expected to find a root partition on device /dev/sda2 and did not. The numbers in the error message are major and minor device numbers (in hex) [see Section 3.2 for the mapping to device names]. In such situations the "root" boot option can be useful (also the rdev command can be used to modify where the boot image looks for the root partition).

Lilo's configuration file /etc/lilo.conf can take the "root=" option in two ways. The normal way is a line like: 'root=/dev/sda2'. In this case /dev/sda2 is converted into major and minor numbers based on the state of the system when the lilo command is executed. This can be a nuisance, especially if hardware is going to be re-arranged. The other way is a line of the form: 'append="root=/dev/sda2"' In this case the /dev/sda2 is passed through to the kernel the next time it is started. This is the same as giving the "root=/dev/sda2" string at the kernel boot time prompt. It is interpreted by the kernel at startup (once the HBAs and their attached devices have been recognized) and thus is more flexible.

Chapter 6. Modules and their Parameters

There are many SCSI related modules. The mid and upper level modules are listed below:

• scsi_mod.o

• sd_mod.o

• sr_mod.o

• st.o [osst.o]

• sg.o

Notice that the first 3 have "_mod" appended to their normal driver names. Lower level drivers tend to use the name (or an abbreviation) of the HBA's manufacturer (e.g. advansys) plus optionally the chip number of the major controller chip (e.g. sym53c8xx for symbios controllers based on the NCR 53c8?? family of chips).

All SCSI modules depend on the mid level. This means if the SCSI mid level is not built into the kernel and if scsi_mod.o has not already been loaded then a command like modprobe st will cause the scsi_mod.o module to be loaded. There could well be other dependencies, for example modprobe sr_mod will also cause the cdrom module to be loaded if it hasn't been already. Also if the SCSI mid level is a module, then all other SCSI subsystem drivers must be modules (this is enforced by the kernel build configuration tools).

Modules can be loaded with the modprobe <module_name> command which will try to load any modules that the nominated <module_name> depends on. Also <module_name> does not need the trailing ".o" extension which is assumed if not given. The insmod <module_name> command will also try and load <module_name> but without first loading modules it depends on. Rules for how modules can cause other modules to be loaded (with appropriate parameters appended) are usually placed in the file /etc/modules.conf. [Note that in earlier Linux kernels this file was often called /etc/conf.modules.] For further information about the format of this file try man modules.conf.

Any module can have its allowable command line parameters queried with this command: modinfo -p <module_name>.

When upper level drivers are initialized and if there are no hosts active then the mid level will attempt to load a module called "scsi_hostadapter". An "alias" can then be used to associate "scsi_hostadapter" with the actual name of the lower level (adapter) driver. For example, a line like "alias scsi_hostadapter aic7xxx" in the /etc/modules.conf file would cause the aic7xxx module to be loaded (if there were no lower level drivers already active). [4]

There is a special relationship between the module parameter "scsi_hostadapter" and the initrd file system. For more information see man initrd and man mkinitrd. [5]

Chapter 7. Proc pseudo file system

The proc pseudo file system provides some useful information about the SCSI subsystem. The kernel configuration option that selects "proc_fs" is CONFIG_PROC_FS and in almost all cases it should be selected. SCSI specific information is found under the directory /proc/scsi. Probably the most commonly accessed entry is cat /proc/scsi/scsi which lists the attached SCSI devices. See Section 8.3 for more details.

The lower level drivers are allocated proc_fs entries of the form:

/proc/scsi/<driver_name>/<scsi_adapter_number>

where the <driver_name> is something like "aic7xxx" or "BusLogic". The <scsi_adapter_number> (also known as the host number) is the same number that was discussed in Section 3.1. Note that one driver may control one or more hosts. What is stored in this file is lower level driver dependent (and in the case of some adapter drivers it is possible to set parameters via this file). When reporting problems to newsgroups or maintainers it is useful to include the output of this file (e.g. cat /proc/scsi/aic7xxx/0 ).

The cdrom driver provides information about attached cdrom devices in the /proc/sys/dev/cdrom directory. This will include both SCSI devices (i.e. those controlled by the sr driver) and IDE devices (i.e. those controlled by the ide-cd driver). See Section 9.2.3.

The sg driver provides information about its state and attached hosts and devices in the /proc/scsi/sg directory. See Section 9.4.3.

More general information on the proc pseudo file system can be found in the kernel source file: /usr/src/linux/Documentation/filesystems/proc.txt.

Chapter 8. Mid Level, Unifying layer

The SCSI mid level is common to all usage of the SCSI subsystem. Probably its most important role is to define internal interfaces and services that are used by all other SCSI drivers. These internal mechanisms are not discussed in this document [see ref: W2].

The primary kernel configuration parameter "CONFIG_SCSI" determines whether the mid level is built in (when "=y") or a module (when "=m"). If "CONFIG_SCSI=m" then all other SCSI subsystem drivers must also be modules.

When the mid level is built as a module then it probably never needs to be loaded explicitly because using 'modprobe' to load any other SCSI subsystem module will cause the mid level to be loaded first (if it is not already).

Some upper and lower level drivers do not (fully) load if there are no devices for that driver to control. Sometimes the report is loud as in this case for the imm driver which controls zip drives connected to a parallel port:

$ modprobe imm imm.o: init_module: No such device

lsmod will not show the "imm" module as loaded. In other cases the result is more subtle. For example, if the sg driver is loaded in a system with no (real or pseudo) scsi devices then the /proc/scsi/sg directory will not appear. [It will be created when the first scsi device is recognized.]

---

8.3. proc interface

To display the SCSI devices currently attached (and recognized) by the SCSI subsystem use cat /proc/scsi/scsi.

The output looks like this:

Attached devices: Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-Access ANSI SCSI revision: 03

After the "Attached devices:" line there are 3 lines for each recognized device. The first of these lines is SCSI address information discussed in Section 3.1. The following 2 lines of data are obtained from a INQUIRY command that was performed on the device when it was attached. See Section 9.4 for the relationship between the ordering of these devices compared with the sg driver's ordering (which most of the time is the same).

Existing devices can be removed using echo "scsi remove-single-device <h> <b> <t> <l>" > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command. The removal will fail if the device is busy (e.g. if a file system on the device is mounted).

New devices can be added using echo "scsi add-single-device <h> <b> <t> <l>" > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command. [9]

The SCSI subsystem does not support hot-plugging of SCSI devices (there may also be electrical issues on the associated SCSI parallel bus). It is recommended that those who use add+remove-single-device make sure that other devices on that SCSI bus are inactive if re-plugging is going to take place.

To output a list of internal SCSI command blocks use echo "scsi dump <n>" > /proc/scsi/scsi where the numeric value of <n> doesn't matter. This is probably only of interest to people chasing down bugs within the SCSI subsystem.

To start (or stop) logging information being sent to the console/log use echo "scsi log <token> <n>" > /proc/scsi/scsi where <token> is one of: {all, none, error, timeout, scan, mlqueue, mlcomplete, llqueue, llcomplete, hlqueue, hlcomplete, ioctl} and <n> is a number between 0 and 7. The tokens "all" and "none" don't take an <n> argument. Prefix meanings:

hl upper level drivers [exception: sg uses "timeout"] ml mid level ll lower level drivers [adapter drivers often have there own flags]

The value "0" turns off logging while "7" maximizes the volume of output. Logging information will only be output if CONFIG_SCSI_LOGGING was selected in the kernel build.

Warning: "scsi log all" (and several other variants) can cause a logging infinite loop if the log file (typically /var/log/messages ) lies on a SCSI disk. Either turn off the kernel logging daemon or direct its output to a non SCSI device.

Chapter 9. Upper level drivers

The upper level drivers maintain the kernel side of the OS interface for the logical class of devices they represent (e.g. disks). They are also responsible for managing certain kernel and SCSI subsystem resources such as kernel memory and SCSI command structures. Applications in the user space access these drivers by opening a special file (block or char) typically found in the /dev directory tree.

Chapter 10. Lower Level drivers

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.

        echo "log:1" > /proc/ide/hdx/settings

        echo "using_dma:0" > /proc/ide/hdx/settings

Chapter 11. Raw devices

A raw device can be bound to an existing block device (e.g. a disk) and be used to perform "raw" IO with that existing block device. Such "raw" IO bypasses the caching that is normally associated with block devices. Hence a raw device offers a more "direct" route to the physical device and allows an application more control over the timing of IO to that physical device. This makes raw devices suitable for complex applications like Database Management Systems that typically do their own caching.

Raw devices are character devices (major number 162). The first minor number (i.e. 0) is reserved as a control interface and is usually found at /dev/rawctl. A utility called raw (see man raw) can be used to bind a raw device to an existing block device. These "existing block devices" may be disks or cdroms/dvds whose underlying interface can be anything supported by Linux (e.g. IDE/ATA or SCSI).

A sequence of commands listing the raw devices and then binding a SCSI disk partition followed by binding the whole disk looks like this on my system:

$ ls -lR /dev/raw* crw-r--r-- 1 root root 162, 0 Dec 6 06:54 /dev/rawctl /dev/raw: total 0 crw-r--r-- 1 root root 162, 1 Dec 6 06:54 raw1 crw-r--r-- 1 root root 162, 2 Dec 6 06:54 raw2 crw-r--r-- 1 root root 162, 3 Dec 6 06:54 raw3 crw-r--r-- 1 root root 162, 4 Dec 6 06:54 raw4 $ $ raw -qa $ $ raw /dev/raw/raw1 /dev/sda3 /dev/raw/raw1: bound to major 8, minor 3 $ raw /dev/raw/raw2 /dev/sda /dev/raw/raw2: bound to major 8, minor 0 $ raw -qa /dev/raw/raw1: bound to major 8, minor 3 /dev/raw/raw2: bound to major 8, minor 0

The normal array of system calls for character devices are available on raw devices. The size of the transfer for read(2) and write(2) must be an integral multiple of the physical device's block size. For a disk this will be its sector size which is normally 512 bytes. The data buffer given to read() and write() system calls must be aligned to the block size. The lseek(2) call needs to align its file read/write offset to a block boundary as well. The pread(3) call (see man pread) combines a read() and an lseek() and can be useful with raw devices (ditto with pwrite() ). Care should be taken with offsets greater than 2 GB (or perhaps 4 GB) on 32 bit architectures where the "off_t" type is 32 bits long. One solution is to use the _llseek() call (see man llseek).

Unix utilities such as recent versions of dd and lmdd (from the lmbench suite of programs) can be used to move data to and from "raw" devices as they meet the above-mentioned block alignment requirements. Recent versions of the sg_dd command in the sg_utils package can access both raw and sg devices.

Also note that if the physical device has an odd number of sectors (as shown by blockdev --getsize /dev/raw/raw*), the last sector will not be accessible using raw IO.

If a block device is being accessed via a bound raw device and also via its normal block interface then there is no cache coherency between the two access mechanisms. For example if /dev/sda1 was both mounted and being accessed via a bound raw device then there could be data inconsistencies.

Chapter 12. Devfs pseudo file system

The main documentation for devfs can be found at: reference W5. The devfs name conventions for the SCSI subsystem are outlined in Section 3.3. Devfs is selected by the kernel build option CONFIG_DEVFS_FS and whether it is mounted at boot time (as /dev) or not is controlled by the kernel build option CONFIG_DEVFS_MOUNT. The latter option can be overridden by the kernel boot time options "devfs=mount" or "devfs=nomount", whichever is appropriate.

The devfs SCSI node names with their default permissions are:

disc rw------- whole disk including mbr part1 rw------- first partition {...p1} ... part15 rw------- 15th partition {...p15} cd rw-rw-rw- cd or dvd devices mt rw-rw-rw- tape mode 0 with rewind {...m0} mtl rw-rw-rw- tape mode 1 with rewind {...m1} mtm rw-rw-rw- tape mode 2 with rewind {...m2} mta rw-rw-rw- tape mode 3 with rewind {...m3} mtn rw-rw-rw- tape mode 0 with no rewind {...m0n} mtln rw-rw-rw- tape mode 1 with no rewind {...m1n} mtmn rw-rw-rw- tape mode 2 with no rewind {...m2n} mtan rw-rw-rw- tape mode 3 with no rewind {...m3n} generic rw-r-----

These node names are only present if the corresponding device (or sub-entities of the device (e.g. partitions)) and driver are present. For example if there is no sg driver present then there is no "generic" device name. The strings that appear above in braces are appended to the abridged "c0b0t0u0" notations outlined below as appropriate.

The devfs file names that are block or character special files will be called the primary device names in this description. The devfs daemon, called devfsd, introduces many symbolic links to those primary device names. This is done both for backward compatibility and convenience. These symbolic links will be called secondary device names.

The secondary device names are controlled by the devfsd configuration file usually found in /etc/devfsd.conf . Following is a list of secondary device names when the default devfsd.conf file is used:

Secondary name slink to this primary device name -------------------------------------------------------------- /dev/sda /dev/scsi/host0/bus0/target2/lun0/disc /dev/sda1 /dev/scsi/host0/bus0/target2/lun0/part1 /dev/sd/c0b0t2u0 /dev/scsi/host0/bus0/target2/lun0/disc /dev/sd/c0b0t2u0p1 /dev/scsi/host0/bus0/target2/lun0/part1 /dev/sr0 /dev/scsi/host0/bus0/target4/lun0/cd /dev/sr/c0b0t4u0 /dev/scsi/host0/bus0/target4/lun0/cd /dev/st0 /dev/scsi/host1/bus0/target0/lun0/mt /dev/nst0a /dev/scsi/host1/bus0/target0/lun0/mtan /dev/st/c1b0t0u0m0 /dev/scsi/host1/bus0/target0/lun0/mt /dev/st/c1b0t0u0m3n /dev/scsi/host1/bus0/target0/lun0/mtan /dev/sg0 /dev/scsi/host0/bus0/target2/lun0/generic /dev/sg1 /dev/scsi/host0/bus0/target4/lun0/generic /dev/sg2 /dev/scsi/host1/bus0/target0/lun0/generic /dev/sg/c0b0t2u0 /dev/scsi/host0/bus0/target2/lun0/generic /dev/sg/c0b0t4u0 /dev/scsi/host0/bus0/target4/lun0/generic /dev/sg/c1b0t0u0 /dev/scsi/host1/bus0/target0/lun0/generic

Note that the more common /dev/scd0 variant for SCSI cdroms is not supported. There are also /dev/discs, /dev/cdroms and /dev/tapes directories that contain symbolic links to all devices (i.e. not just SCSI devices) that fall into that categorization:

Secondary name slink to this primary device ------------------------------------------------------------ /dev/discs/disc0 /dev/ide/host0/bus0/target0/lun0 * /dev/discs/disc1 /dev/scsi/host0/bus0/target2/lun0 * /dev/cdroms/cdrom0 /dev/ide/host0/bus1/target1/lun0/cd /dev/cdroms/cdrom1 /dev/scsi/host0/bus0/target4/lun0/cd /dev/tapes/tape0 /dev/scsi/host1/bus0/target0/lun0 *

Those entries marked with "*" are directories containing the primary devices. Note that IDE/ATA devices are listed before SCSI devices. These secondary device names mimic the same persistence rules as the primary device names. So when a SCSI device (?), or its lower level driver or its upper level driver are removed then so are the primary and secondary device names associated with it.

When devfs is mounted as /dev, the old "/dev/sda6" type can still be used in some contexts. This may be convenient if typing is required at the kernel boot time prompt. For example if a user wants to change the root partition on a "devfs" machine then any of the following examples may be used as a kernel boot time option:

root=/dev/sda6 root=/dev/scsi/host0/bus0/target0/lun0/part6 root=/dev/sd/c0b0t0u0p6

There are many device scanning programs that expect to see the pre-devfs device names present and it will some time before they become devfs aware. Also some programs rely on a open of /dev/sg0 (for example) to load the sg driver (assuming it is a module and not already loaded). This can be arranged by an entry in /etc/devfsd.conf file of:

LOOKUP sg.* MODLOAD

and the following in /etc/modules.devfs :

probeall /dev/sg scsi-hosts sg alias /dev/sg* /dev/sg

The sg device permissions can be changed with this entry in the /etc/devfsd.conf file:

REGISTER scsi/host.*/bus.*/target.*/lun.*/generic PERMISSIONS 0.0 rw-rw-rw-

See "man devfsd" for more information.

An application can determine whether devfs is active by the presence or otherwise of the file /dev/.devfsd.

A feature of a /dev directory based on a persistent file system (e.g. ext2) is the ability to associate permissions with a device file name and keep them from one boot to the next. As noted above the default action of devfs is to assign device file name permissions anew each time a machine is booted. The PERMISSIONS action in the /etc/devfsd.conf can be used to assert permissions but this may be considered a little awkward. The devfs document (W5) describes a method for getting the best of both worlds. This technique relies on the recently added feature in lk 2.4 to mount the same file system at multiple points.