This page discusses the impact on the scsi subsystem of devfs, emphasizingnaming issues. More discussion about the SCSI subsystem in the Linux kernel2.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 onRedHat 7.0 .
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 aloneand poke around with devfs first. I did this by building the kernel withthese 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 havinga useful system. At this stage I did not load up devfsd (user space daemonavailable from Richard's site) because it muddies the waters a little.The following discussion uses this environment to look at the relationshipsbetween devfs and the scsi sub-system. Replacing the classical /dev withdevfs is discussed later.
Another thing that should be stressed is that modutils-2.3.10 or lateris required [see the linux/Documentation/Changes file for its location].The modutils-2.3.11 package is now available and is preferred.
$ 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 informationin the /proc/scsi/sg directory. Here is a listing of hosts. In the originallinux scsi parlance the first line corresponds toscsi0, the secondline toscsi1, etc. One thing to note is that there are no devicesconnected 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 leveldirectory 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-systemwhere 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 scsisub-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: 00Id: 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 namesare 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 toshow 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 devicenames is:
/dev/sda .../disc
/dev/sda1 .../part1
/dev/sda2 .../part2
etc.
The "generic" entries on lines 2, 4, 5, 7, 9 and 11 above correspondto the old device names of /dev/sg0,1,2,3,4,5 . Also the above leaf nodesare where the device mknods are (other entries for this cd will be symlinksto 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 lineindevice-strs anddevices corresponds to what was formerlycalled /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-ROMDVD-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.
$ 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 showsa hole in the device mapping as /dev/sg2 (char major 21, minor 2) is nolonger 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 hostnumber (5) leaving host3 orphaned. Adding a low level driver forces a scanof its bus (or buses) and the DVD-303 is found again. The relevant partsof /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-introducedhost getting a new host number while the device re-adopted its former positionat /dev/sg2 (char major 21, minor 2):
$ 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
Adaptec 1542
$ 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 isperformed:
$ echo "scsi add-single-device 0 0 5 0" > /proc/scsi/scsi
After that /proc/scsi/scsi looks a little strange: notice the scanneron scsi id 5 appears after the cd writer on scsi id 6:
$ 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: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: UMAX Model: Astra 1220S Rev: V1.2
Type: Scanner ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DCHS04U Rev: 2727
[... as before]
The addition and removal of this device tracked a similar pattern (atleast from the point of view of devfs) to adding and removing a host. Namelydevfs concentrated on devices and when they disappeared the "lun" leveland below was truncated. Since the additional device was a scanner thenthe only leaf entry for the device was:
./host0/bus0/target5/lun0/generic
$ 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 linksto mass storage devices. Each symbolic link is to a directory which inthe case of "disc1" contains disc, part1, part2, part5, part6, part7 andpart8. It would seem that ide disks get listed before scsi disks (and USBand firewire mass storage devices would probably be found here as well).Equating the old and new notation yields /dev/hda==/mnt/devfs/discs/disc0/discand /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. Soequating 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. Exactlywhat is added will depend on the contents of the /etc/devfsd.conf file.Using the default "conf" file supplied with the devfsd tarball yields thescsi device names we are used to in Linux. Notice these are all symboliclinks which can cause some problems (see later). Devfsd also seems to addnew subdirectories called sd, sr, st and sg that introduce yet anothernotation. 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.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
[snipped first part of posting]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Zoltan's patch to change probeall to alias was needed because he didn'thave the required modutils package. I had the same problem until I downloadedftp://ftp.ocs.com.au/pub/modutils/v2.3/modutils-2.3.10.tar.gz [also availableas an rpm] and installed it. Also the "sleep 2" requirement seems to bea quirk required by RedHat 6.0 that was not needed in RH 6.1 or later.
So my steps were to:
$ cat /etc/securetty
tty1
tty2
....
tty8
1
2
3
4
5
6
7
8
Note:The above solution weakens security allowingother users (e.g. across a network on /dev/pty1) to login as root. Thiswould 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 changeto 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 itis from Xwrapper so pam may well be involved). This only effects non-rootusers (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 comesfrom either a pam_authenticate() or pam_acc_mgmt() call in Xwrapper. Finallyfound the file to patch [for RH 6.2]:
--- /etc/security/console.perms.orig Sat Apr 1716: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 aleading "vc/" that was not required previously [for RH 7.0]:
--- /etc/security/console.perms_rh70 Tue Aug 2221: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. Thisuses a boot time option calledscsihosts which a very useful facilitysince it is not easy to determine (before trying) which host numbers willbe allocated when an additional scsi adapter is added.
How can you determine whether devfs is active in /dev or not? Devfsdoesn't have any procfs presence. The command "df -a" does not showdevfs (but it does show procfs and the /dev/pts pseudo file systems). Theexistence of the file /dev/.devfsd (which is a char special) can be takenas an accurate guide. [Richard Gooch confirmed that this is the approvedmethod of determination but noted it could be other than a character specialfile in the future.]
# You may comment out the above and uncomment the following if you've
# configured your system to use the original "new" devfs namesor 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.*/genericPERMISSIONS 0.0 644
This is mainly pro forma as provided by with the devfsd package. Thereis 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'twork make sure that you are using modutils-2.3.10 or later.]
It is important to use an appropriate /etc/modules.conf file for theabove "MODLOAD"s to work. For example, if a user tries to open /dev/sg0and 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 towork 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 mergedin.
As an alternative to devfsd (or perhaps supporting it), the devfs documentationproposes a "tar czf dev_persist.tgz /dev" type solution. This will makedevice specific information, links and permissions persistent from oneboot to the next. This involves creating a tarball during orderly shutdownand extracting it again during the startup sequence. There is also a newtechnique which involves remounting the original /dev (i.e. the one heldon disk) at another mount point and using it as a reference for ownershipand permissions when devfsd "overmounts" /dev . It is a new feature in2.4 kernels that allows a file system (or part of it) to be mounted at2 or more points.
Both cdrecord and cdparanoia offer facilities to scan for devices thatthey may wish to control. Two utility programs that are called sg_scanand 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 andcan cope with any configuration of devfs (and devfsd) would seem to bechallenging.
It will be interesting to see how the various distributions react todevfs in their initial 2.4 series kernel releases. Meanwhile a few scsidevice 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 informationin this page still applies.
Doug Gilbert
22nd January 2001 19:00