DEVFS and SCSI

Introduction

The device pseudo file system (devfs) was added to the Linux development source tree in 2.3.46 and will be present in the forthcoming 2.4 series of kernels. Richard Gooch first proposed devfs 2 years ago and has been maintaining patches external to the main kernel source tree since then. It's inclusion has been controversial but in the month or so it has now been present its detractors are beginning to accept that it has a place. It should be stressed that devfs's use is optional and is unlikely to be the default in at least the initial lk 2.4 distributions when they materialize.

This page discusses the impact on the scsi subsystem of devfs, emphasizing naming issues. More discussion about the SCSI subsystem in the Linux kernel 2.4 series can be found at < http://www.torque.net/scsi/SCSI-2.4-HOWTO>.

This page has been updated for changes needed to get devfs working on RedHat 7.0 .

A bad start

Well if you ignore the documentation < www.atnf.csiro.au/~rgooch/linux/docs/devfs.html> and just select devfs in your kernel configuration (and its "mount" option) then build and reboot you will probably not get far. On my box (i386 with a RH 6.2 distro) it found the kernel, mounted the root file system read-only and crashed into single user mode. This occurred because the boot sequence couldn't find any of the partitions referred to in /etc/fstab. After surveying the wreckage and reading Richard's document (twice) I decided on a more cautious approach. Formerly this was to put the line 'append="devfs=nomount"' into lilo (i.e. pass the boot parameter "devfs=nomount"). A more recent change was to add the CONFIG_DEVFS_MOUNT build option which controls whether devfs is mounted automatically as /dev or not. [The kernel boot time options (devfs=mount or devfs=nomount) can be still used to override the build time option.]

When devfs mounts at /dev it hides anything you previously had there. Until you realize the impact of this it may be better to leave /dev alone and poke around with devfs first. I did this by building the kernel with these options:
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=n
CONFIG_DEVFS_DEBUG=n # if trouble occurs perhaps this could be turned on
and making a mount point at /mnt/devfs and then doing:
$ mount -n -t devfs none /mnt/devfs

This way you get to look at devfs in its pure state while still having a useful system. At this stage I did not load up devfsd (user space daemon available from Richard's site) because it muddies the waters a little. The following discussion uses this environment to look at the relationships between devfs and the scsi sub-system. Replacing the classical /dev with devfs is discussed later.

Another thing that should be stressed is that modutils-2.3.10 or later is required [see the linux/Documentation/Changes file for its location]. The modutils-2.3.11 package is now available and is preferred.

Devfs and the scsi sub-system

First, here are the scsi devices which are attached to my system:

$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: YAMAHA   Model: CRW4416S         Rev: 1.0g
Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: IBM      Model: DCHS04U          Rev: 2727
Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 02 Lun: 00
Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10
Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: Foo Inc Model: XYZZY            Rev: 1
Type:   Direct-Access                    ANSI SCSI revision: 01
Host: scsi4 Channel: 00 Id: 01 Lun: 00
Vendor: Foo Inc Model: XYZZY            Rev: 1
Type:   Direct-Access                    ANSI SCSI revision: 01
Host: scsi4 Channel: 00 Id: 02 Lun: 00
Vendor: Foo Inc Model: XYZZY            Rev: 1
Type:   Sequential-Access                ANSI SCSI revision: 01

Recently (since lk 2.3.43) the sg driver provides procfs information in the /proc/scsi/sg directory. Here is a listing of hosts. In the original linux scsi parlance the first line corresponds to scsi0, the second line to scsi1, etc. One thing to note is that there are no devices connected to the ide-scsi host:

$ cat /proc/scsi/sg/host_strs
AdvanSys SCSI 3.2M: ISA PnP 16 CDB: BIOS C800, IO 120/F, IRQ 10, DMA 7
AdvanSys SCSI 3.2M: PCI Ultra-Wide: BIOS D8000/7FFF, IO E400/3F, IRQ 11
SCSI host adapter emulation for IDE ATAPI devices
Adaptec 1542
SCSI DEBUG

So what does devfs look like? Following is its uncluttered top level directory after these modules have been loaded: cdrom, sr_mod, st, sg, aha1542 and scsi_debug (while other things you can see in the scsi sub-system where built into the kernel).

$ ls /mnt/devfs
cdroms   discs   ide   misc     port      pts     rd    sound tty      vcc
console floppy kmem netlink printers pty     root tapes urandom zero
cua      full    mem   null     ptmx      random scsi tts    vc

There is a lot more happening under the covers, especially in the scsi sub-tree. What follows is an edited "du -a" to show only the leaf nodes. So the cdrom referred to by "cat /proc/scsi/scsi" as "scsi0 Channel: 00 Id: 06 Lun: 00" with a former device name /dev/scd0 has become /mnt/devfs/scsi/host0/bus0/target6/lun0/cd . The "lun" name is about the only thing that hasn't changed! The new names are reasonably self explanatory and are consistent with the ide sub-tree. Note that host2 (ide-scsi emulation) doesn't get mentioned.

$ du -a /mnt/devfs/scsi      # edited to show leaves only
0       ./host0/bus0/target6/lun0/cd
0       ./host0/bus0/target6/lun0/generic
0       ./host1/bus0/target0/lun0/disc,part1,part2,part5,part6,part7,part8
0       ./host1/bus0/target0/lun0/generic
0       ./host3/bus0/target2/lun0/generic
0       ./host3/bus0/target2/lun0/cd
0       ./host4/bus0/target0/lun0/generic
0       ./host4/bus0/target0/lun0/disc,part1,part2,part3
0       ./host4/bus0/target1/lun0/generic
0       ./host4/bus0/target1/lun0/disc,part1,part2,part3
0       ./host4/bus0/target2/lun0/generic
0       ./host4/bus0/target2/lun0/mt,mtn,mtl,mtln,mtm,mtmn,mta,mtan

Looking at the 3rd line of output above, the mapping from the old device names is:
/dev/sda     .../disc
/dev/sda1    .../part1
/dev/sda2    .../part2
etc.

The "generic" entries on lines 2, 4, 5, 7, 9 and 11 above correspond to the old device names of /dev/sg0,1,2,3,4,5 . Also the above leaf nodes are where the device mknods are (other entries for this cd will be symlinks to this). For example:

$ ls -l host3/bus0/target2/lun0/cd
brw-rw-rw- 1 root root 11, 1 Dec 31 1969 host3/bus0/target2/lun0/cd

Another recent addition to sg is device information. The first line in device-strs and devices corresponds to what was formerly called /dev/sg0 (char major 21, minor 0), the second line to /dev/sg1, etc. Note that the ordering is currently the same as "cat /proc/scsi/scsi" but diverges in the next section.

$ cd /proc/scsi/sg
$ cat device_strs
YAMAHA          CRW4416S                1.0g
IBM             DCHS04U                 2727
PIONEER         DVD-ROM DVD-303         1.10
Foo Inc                   XYZZY           1
Foo Inc                   XYZZY           1
Foo Inc                   XYZZY           1

$ cat device_hdr devices
host    chan    id      lun     type    bopens qdepth busy
0       0       6       0       5       0       4       0
1       0       0       0       0       3       63      0
3       0       2       0       5       0       1       0
4       0       0       0       0       0       1       0
4       0       1       0       0       0       1       0
4       0       2       0       1       0       1       0

As expected, these tie in with the devfs scsi sub-tree.

Adding and removing Hosts and Devices

Now let's see what happens when we remove the aha1542 low level scsi adapter that has the Pioneer DVD-303 (cd/dvd reader) connected to it. Below is a "du -a" of the effected part of devfs. It seems as though devfs recognizes that the device is gone but has no concept of the associated host being removed. The bus0 and the target2 look like remnants but are probably benign.

$ du -a /mnt/devfs/scsi/host3    # after 'rmmod aha1542' (host3)
0       host3/bus0/target2
0       host3/bus0
0       host3

Here is sg's procfs output showing host 3 is now inactive. It also shows a hole in the device mapping as /dev/sg2 (char major 21, minor 2) is no longer associated with a device.

$ cd /proc/scsi/sg
$ cat host_strs
AdvanSys SCSI 3.2M: ISA PnP 16 CDB: BIOS C800, IO 120/F, IRQ 10, DMA 7
AdvanSys SCSI 3.2M: PCI Ultra-Wide: BIOS D8000/7FFF, IO E400/3F, IRQ 11
SCSI host adapter emulation for IDE ATAPI devices
<no active host>
SCSI DEBUG

$ cat device_hdr devices
host    chan    id      lun     type    bopens qdepth busy
0       0       6       0       5       0       4       0
1       0       0       0       0       3       63      0
-1      -1      -1      -1      -1      -1      -1      -1
4       0       0       0       0       0       1       0
4       0       1       0       0       0       1       0
4       0       2       0       1       0       1       0

Next the aha1542 module is re-introduced. Note that it gets a new host number (5) leaving host3 orphaned. Adding a low level driver forces a scan of its bus (or buses) and the DVD-303 is found again. The relevant parts of /mnt/devfs/scsi now are:

$ du -a host3 host5
0       host3/bus0/target2
0       host3/bus0
0       host3
0       host5/bus0/target2/lun0/generic
0       host5/bus0/target2/lun0/cd
0       host5/bus0/target2/lun0
0       host5/bus0/target2
0       host5/bus0
0       host5

The sg host and device mapping follow a similar pattern with the re-introduced host getting a new host number while the device re-adopted its former position at /dev/sg2 (char major 21, minor 2):

$ cat device_hdr devices
host    chan    id      lun     type    bopens qdepth busy
0       0       6       0       5       0       4       0
1       0       0       0       0       3       63      0
5       0       2       0       5       0       1       0
4       0       0       0       0       0       1       0
4       0       1       0       0       0       1       0
4       0       2       0       1       0       1       0

During these test there was a scanner powered off connect to host0. Now it is powered on and after it has settled the following command is performed:

$ echo "scsi add-single-device 0 0 5 0" > /proc/scsi/scsi

After that /proc/scsi/scsi looks a little strange: notice the scanner on scsi id 5 appears after the cd writer on scsi id 6:

The addition and removal of this device tracked a similar pattern (at least from the point of view of devfs) to adding and removing a host. Namely devfs concentrated on devices and when they disappeared the "lun" level and below was truncated. Since the additional device was a scanner then the only leaf entry for the device was:
./host0/bus0/target5/lun0/generic

Other devfs references to scsi devices

The root partition get its own symbolic entry in the top level devfs directory. If your root partition is on an ide disk then the link will look similar but start with an "ide". Notice the datestamp is at the Unix epoch.

$ ls -l /mnt/devfs/root
lr-xr-xr-x 1 root root 0 Dec 31 1969
root -> scsi/host1/bus0/target0/lun0/part6

There is a subdirectory called "discs" that contains symbolic links to mass storage devices. Each symbolic link is to a directory which in the case of "disc1" contains disc, part1, part2, part5, part6, part7 and part8. It would seem that ide disks get listed before scsi disks (and USB and firewire mass storage devices would probably be found here as well). Equating the old and new notation yields /dev/hda==/mnt/devfs/discs/disc0/disc and /dev/sda==/mnt/devfs/discs/disc1/disc etc.

$ ls -l /mnt/devfs/discs
total 0
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            disc0 -> ../ide/host0/bus0/target0/lun0
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            disc1 -> ../scsi/host1/bus0/target0/lun0
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            disc2 -> ../scsi/host4/bus0/target0/lun0
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            disc3 -> ../scsi/host4/bus0/target1/lun0

By contrast the "cdroms" subdirectory refers directly to the cd device. My guess is that any active ide cdroms would appear before scsi ones. So equating the old and new notation again yields /dev/scd0==/mnt/devfs/cdroms/cdrom0 .

$ ls -l /mnt/devfs/cdroms
total 0
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            cdrom0 -> ../scsi/host0/bus0/target6/lun0/cd
lr-xr-xr-x   1 root     root            0 Dec 31 1969
                            cdrom1 -> ../scsi/host5/bus0/target2/lun0/cd

The "tapes" subdirectory follows a similar pattern to the "discs" subdirectory. It points to the directory containing the various tapedevices: mt, mtn, mtl, mtln, mtm, mtmn, mta and mtan.

$ ls -l /mnt/devfs/tapes
total 0
lr-xr-xr-x 1 root root 0 Dec 31 1969
tape0 -> ../scsi/host4/bus0/target2/lun0

When devfsd is running other cross-referencing of devices occurs. Exactly what is added will depend on the contents of the /etc/devfsd.conf file. Using the default "conf" file supplied with the devfsd tarball yields the scsi device names we are used to in Linux. Notice these are all symbolic links which can cause some problems (see later). Devfsd also seems to add new subdirectories called sd, sr, st and sg that introduce yet another notation. These are all symbolic links as before.

$ ls /mnt/devfs/sd
c0b0t0u0    c0b0t0u0p5 c0b0t0u0p8 c3b0t0u0p2 c3b0t1u0p1
c0b0t0u0p1 c0b0t0u0p6 c3b0t0u0    c3b0t0u0p3 c3b0t1u0p2
c0b0t0u0p2 c0b0t0u0p7 c3b0t0u0p1 c3b0t1u0    c3b0t1u0p3

$ ls /mnt/devfs/st
c3b0t2u0m0 c3b0t2u0m1 c3b0t2u0m2 c3b0t2u0m3
c3b0t2u0m0n c3b0t2u0m1n c3b0t2u0m2n c3b0t2u0m3n

If nothing else, this notation should be easy to parse.

Installing devfs

If you are feeling adventurous then you can try and use devfs as it was designed and replace (or hide) your existing /dev . Prudence would dictate that you setup lilo (or whatever) so you can boot into some earlier (or safer) kernel if devfs makes your system unusable. After my initial failures I was inspired by this posting from Boszormenyi Zoltan <zboszor@externet.hu> to the linux kernel newsgroup on 18th February 2000.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
[snipped first part of posting]

I have some problems with it now. I couldn't log in as root. Again. :-)
However, adding [1-8] to /etc/securetty helped. /dev/tty[1-8] are symlinks
to /dev/vc/[1-8]... Just in case someone else has fallen into this trap.

Now the real problems. The provided modules.conf sample does not work,
I mean it does not load all SCSI drivers correctly for me. Try this patch
against the provided modules.conf for e.g. SCSI disks.

**************************************
--- modules.conf.devfs Fri Feb 18 09:15:24 2000
+++ modules.conf        Fri Feb 18 11:02:04 2000
@@ -8,7 +8,10 @@
alias          gen-watchdog    pcwd
alias          gen-md          raid0
alias          /dev/joysticks joystick
-probeall       scsi-hosts      sym53c8xx
+alias          scsi-hosts      sym53c8xx
+add above      scsi-hosts      ppa
+alias          parport_lowlevel        parport_pc
+options        parport_pc              io=0x378 irq=7

###############################################################################
# Generic section: do not change
@@ -29,7 +32,8 @@
probeall /dev/ide ide-probe-mod ide-disk ide-cd ide-tape ide-floppy

# SCSI HDDs
-probeall       /dev/sd         scsi-hosts sd_mod
+below          sd_mod          scsi-hosts
+alias          /dev/sd         sd_mod
alias          /dev/sd*        /dev/sd

# SCSI CD-ROMs
**************************************

This way it works for me with and without devfs. E.g. "mdir z:"
(Z: refers to /dev/sda4) nicely loads sym53c8xx and ppa drivers
in this order. Maybe it is the fault of modutils-2.3.9 but using
simply "probeall scsi-hosts sym53c8xx ppa" didn't work.
Which is a shame because this "probeall" thing would be a shorter
and nicer way to describe what I want to load and in what order.

Another problem is that when I try to rmmod all SCSI drivers
_second time_ scsi_mod gets stuck (uninitialized). At the first time
all modules can be removed. But this is not devfs' fault, it happens
with other late 2.3.x as well.

And a note at the end. I start devfsd on boot and I had to put a
"sleep 2" after starting it because the boot sequence stops at
"Mounting local filesystems" twice from five. It is with devfsd-1.3.1.
I looked at devfsd.c and before it forks, it generates the register
events for the already existing device nodes but the events are
handled by the child process. This first round of events should be
handled by the parent process so the startup scripts will not
need this (unreliable amount of) delay. Maybe do_scan_and_service()
should send a "finished startup" event after the last device node
and before the fork() main() should service the events until this
"finished startup"...

Regards,
Zoltan Boszormenyi
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Zoltan's patch to change probeall to alias was needed because he didn't have the required modutils package. I had the same problem until I downloaded ftp://ftp.ocs.com.au/pub/modutils/v2.3/modutils-2.3.10.tar.gz [also available as an rpm] and installed it. Also the "sleep 2" requirement seems to be a quirk required by RedHat 6.0 that was not needed in RH 6.1 or later.

So my steps were to:

set both CONFIG_DEVFS_FS and CONFIG_DEVFS_MOUNT to "y'" in kernel build (alternatively this line can be added to lilo.conf: 'append="devfs=mount"')
fetch devfsd tarball from Richard's site and build and install it (it contains a man page for devfsd)
fetch and install a suitable modutils package (see above) [not needed for RH 7.0]
add "devfsd /dev" just after the "export PATH" line in /etc/rc.d/rc.sysinit (RH 6.0 same in RH 6.2)
add lines into /etc/securetty as shown below (and note warning) [not needed for RH 7.0]
needed a symlink from /dev/mouse to /dev/misc/psaux for gpm
also useful to have a symlink from /dev/cdrom to /dev/cdroms/cdrom0
reboot and watch the bootup sequence messages carefully

I found out what Zoltan was referring to with the inability to login in as root the hard way. My initial circumvention was to login as myself then "su" to root [which is another good reason to have a login other than root]. The last 8 lines of the following file where added to solve this problem:

$ cat /etc/securetty
tty1
tty2
....
tty8
1
2
3
4
5
6
7
8

Note: The above solution weakens security allowing other users (e.g. across a network on /dev/pty1) to login as root. This would not be wise if the computer in question was connected to the internet. In that situation you should probably login in as another user and "su" to root. This is a devfs "issue" that will probably be resolved by a change to the utils-linux package and/or the pam package. You have been warned.

This change to /etc/securetty is not required for RedHat 7.0 .

Startx fails with an "Authentication failed" from xinit (actually it is from Xwrapper so pam may well be involved). This only effects non-root users (i.e. root can start X). With help from William Stearns <wstearns@pobox.com> it was found that the file /var/lock/console/<login_name> was needed (created by root). Without devfs, it is created at the appropriate time, but with it this file is mysteriously missing. The error message comes from either a pam_authenticate() or pam_acc_mgmt() call in Xwrapper. Finally found the file to patch [for RH 6.2]:

--- /etc/security/console.perms.orig Sat Apr 17 16:26:47 1999
+++ /etc/security/console.perms Fri Feb 25 23:53:55 2000
@@ -14,7 +14,7 @@
# man 5 console.perms

# file classes -- these are regular expressions
-<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
+<console>=tty[0-9][0-9]* [0-9][0-9]* :[0-9]\.[0-9] :[0-9]

# device classes -- these are shell-style globs
<floppy>=/dev/fd[0-1]*

This turns out to be another (nasty) side-effect of /dev/tty1 and friends (i.e. virtual consoles) being symbolic links.

A slightly different patch is needed for RedHat 7.0 that requires a leading "vc/" that was not required previously [for RH 7.0]:

--- /etc/security/console.perms_rh70 Tue Aug 22 21:19:33 2000
+++ /etc/security/console.perms Fri Oct 13 20:08:58 2000
@@ -15,7 +15,7 @@
# man 5 console.perms

# file classes -- these are regular expressions
-<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
+<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
<xconsole>=:[0-9]\.[0-9] :[0-9]

# device classes -- these are shell-style globs

The devfs documentation mentions a SCSI host probing facility. This uses a boot time option called scsihosts which a very useful facility since it is not easy to determine (before trying) which host numbers will be allocated when an additional scsi adapter is added.

How can you determine whether devfs is active in /dev or not? Devfs doesn't have any procfs presence. The command "df -a" does not show devfs (but it does show procfs and the /dev/pts pseudo file systems). The existence of the file /dev/.devfsd (which is a char special) can be taken as an accurate guide. [Richard Gooch confirmed that this is the approved method of determination but noted it could be other than a character special file in the future.]

Example /etc/devfsd.conf file

# Sample /etc/devfsd.conf configuration file.
# Richard Gooch <rgooch@atnf.csiro.au>         3-FEB-2000
#
# Enable full compatibility mode for old device names. You may comment these
# out if you don't use the old device names. Make sure you know what you're
# doing!
REGISTER        .*              MKOLDCOMPAT
UNREGISTER      .*              RMOLDCOMPAT

# You may comment out the above and uncomment the following if you've
# configured your system to use the original "new" devfs names or the really
# new names
#REGISTER        vc/.*           MKOLDCOMPAT
#UNREGISTER      vc/.*           RMOLDCOMPAT
#REGISTER        pty/.*          MKOLDCOMPAT
#UNREGISTER      pty/.*          RMOLDCOMPAT
#REGISTER        misc            MKOLDCOMPAT
#UNREGISTER      misc            RMOLDCOMPAT

# You may comment these out if you don't use the original "new" names
REGISTER .* MKNEWCOMPAT
UNREGISTER .* RMNEWCOMPAT

LOOKUP          cdrom           MODLOAD
LOOKUP          sg.*            MODLOAD
#REGISTER       scsi/host.*/bus.*/target.*/lun.*/generic PERMISSIONS 0.0 644

This is mainly pro forma as provided by with the devfsd package. There is a man page ("man devfsd") that explains what is going on here. The last few lines are my additions. [Just a reminder: if this doesn't work make sure that you are using modutils-2.3.10 or later.]

It is important to use an appropriate /etc/modules.conf file for the above "MODLOAD"s to work. For example, if a user tries to open /dev/sg0 and it is not there then the 2nd last line [i.e.: LOOKUP sg.* MODLOAD] will cause the command "modprobe /dev/sg0" to be executed. For this to work lines like these will be required in the /etc/modules.conf file:
# SCSI generic
probeall /dev/sg scsi-hosts sg
alias /dev/sg* /dev/sg
An appropriate /etc/modules.conf is available on the devfs home page. Your current system's contents of /etc/modules.conf may need to be merged in.

As an alternative to devfsd (or perhaps supporting it), the devfs documentation proposes a "tar czf dev_persist.tgz /dev" type solution. This will make device specific information, links and permissions persistent from one boot to the next. This involves creating a tarball during orderly shutdown and extracting it again during the startup sequence. There is also a new technique which involves remounting the original /dev (i.e. the one held on disk) at another mount point and using it as a reference for ownership and permissions when devfsd "overmounts" /dev . It is a new feature in 2.4 kernels that allows a file system (or part of it) to be mounted at 2 or more points.

Scanning scsi device filename space

Many scsi related programs scan the scsi device filenames to find appropriate devices that they may wish to control. An example is SANE which looks for scanners. Ideally SANE likes to find an entry called /dev/scanner but will also check /dev/sg0, sg1 etc. In the extreme situation of a "clean" devfs without devfsd running it won't find anything. A useful categorization for scsi devices is by scsi device type. That is essentially there for disks (/dev/discs), cdroms and tapes but not for other categories, the most important of which would be scanners.

Both cdrecord and cdparanoia offer facilities to scan for devices that they may wish to control. Two utility programs that are called sg_scan and sg_map are available for the sg driver and they also assume the current (pre-devfs) structure of the /dev directory in order to scan for scsi devices. Trying to imagine a scanning algorithm that is backward compatible and can cope with any configuration of devfs (and devfsd) would seem to be challenging.

Conclusion

Devfs brings about a dramatic reduction in the number of file entries in /dev. Prior to devfs on my system 'ls /dev | wc' indicated 2284 files while 'du -a /dev | wc' reported a staggering 5125 files. With devfs (and devfsd running) these number are down to 470 and 960 respectively and these numbers would be much smaller without devfsd running. With devfs it is educational to look into /dev to find out what is actually available on your system. The combination of devfs and procfs makes a lot of accurate information available to the user about available devices and their state.

It will be interesting to see how the various distributions react to devfs in their initial 2.4 series kernel releases. Meanwhile a few scsi device filename scanning algorithms may need to be re-thought.

As more information comes to light, I will try and update this page. Linux kernel 2.4.0-test9 is the current development kernel and the information in this page still applies.

Doug Gilbert
22nd January 2001 19:00