From: Kurt Garloff (garloff@suse.de)
Date: Sat Jun 15 2002 - 08:36:06 EST

Hi SCSI users,

from people using SCSI devices, there's one question that turns up again
and again: How can one assign stable device names to SCSI devices in
case there are devices that may or may not be switched on or connected.

There are a couple of ways to address this problem:
(a) mount by uuid
(b) userspace programs that collect information to create
    alternative and persistent names / device nodes, such
    as Eric Youngdale's scsidev[1], Doug Gilbert's sg_map[2], scsimon[3],
    or Mike Sullivan's scsiname/devnaming[4]
(c) devfs

[1] http://www.garloff.de/kurt/linux/scsidev/
[2] http://www.torque.net/sg/
[3] http://www.torque.net/scsi/scsimon.html
[4] http://oss.software.ibm.com/devreg/

Unfortunately, those approaches all have some deficiencies.
Ad (a): Does only work for ext2 filesystems. For locating
        / one needs additional initrd work.
Ad (b): A considerable amount of work needs to be done in userspace:
        - For all devices types you need to probe possible devices
        - You need to do SCSI_IOCTL_GET_IDLUN to get controller,bus,
          target and unit number
        The problem is that the collection of this information is
        not always successful. If a medium is not inserted, the
        open() fails for some device types, despite O_NONBLOCK.
        Assumptions about the order of devices OTOH are not safe,
        as remove-single-device/add-single-device may result in a
        non-straightforward ordering.
Ad (c): devfs is currently not (yet?) an option for distributions
        due to security and stability considerations.

Life would be easier if the scsi subsystem would just report which SCSI
device (uniquely identified by the controller,bus,target,unit tuple) belongs
to which high-level device. The information is available in the kernel.

Attached patch does this:
garloff@pckurt:/raid5/Kernel/src $ cat /proc/scsi/map
# C,B,T,U Type onl sg_nm sg_dev nm dev(hex)
0,0,00,00 0x05 1 sg0 c:15:00 sr0 b:0b:00
1,0,01,00 0x05 1 sg1 c:15:01 sr1 b:0b:01
1,0,02,00 0x01 1 sg2 c:15:02 osst0 c:ce:00
1,0,03,00 0x05 1 sg3 c:15:03 sr2 b:0b:02
1,0,05,00 0x00 1 sg4 c:15:04 sda b:08:00
1,0,09,00 0x00 1 sg5 c:15:05 sdb b:08:10
2,0,01,00 0x05 1 sg6 c:15:06 sr3 b:0b:03
2,0,02,00 0x01 1 sg7 c:15:07 osst1 c:ce:01
2,0,03,00 0x05 1 sg8 c:15:08 sr4 b:0b:04
2,0,05,00 0x00 1 sg9 c:15:09 sdc b:08:20
2,0,09,00 0x00 1 sg10 c:15:0a sdd b:08:30
3,0,10,00 0x00 1 sg11 c:15:0b sde b:08:40
3,0,12,00 0x00 1 sg12 c:15:0c sdf b:08:50

This allows a simple script to parse the map and create device nodes as

The patch does work the following way.
- Add a find_kdev() function pointer to the high-level driver template
  structure. The function takes a Scsi_Device pointer (points to a
  low-level device) and returns a name and a kdev_t if the device
  is attached to this high-level driver.
- Implement the function for sg, sd, sr, st, osst
- Make scsi/scsi_proc iterate over all devices and calls the high-level
  drivers find_kdev() to find out about it.

Obviously, it can only report the assignment of high-level drivers,
if they are loaded, otherwise the last two columns will stay empty.
(sg is handled especially, as we know it supports all devices.)
If we attach a third high-level device driver, two more columns would show
(Is this variable column number format a problem?)

The patch also includes a simple shell script that does assign
/dev/scsi/sdc2b0t9u0 type names to those devices and making a device nodes
(or optionally symlinks to the old name devices) with this name.

The design allows for two more things:
* using root=/dev/scsi/sdc1b0t9u0p5 without much additional code
  (patch follows in another mail)
* in case we want to support more than 128 scsi disks, the information
  about additional majors can be reported by /proc/scsi/map without further

Patch is against 2.4.19pre10.

I'd like to get it accepted into the kernel.
So please give your criticism ...
I already got some by Doug Gilbert :-)

A patch for 2.5 should be done as well, if the design is OK, of course.


Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:33 EST