[PATCH] /proc/scsi/map

[PATCH] /proc/scsi/map

[Kurt Garloff]

Hi Linus,

find attached a patch (against 2.5.23-dj2) to the SCSI subsystem which 
adds a file /proc/scsi/map, which provides a listing of SCSI devices,
enumerated by the CBTU/HCIL tuple and the high-level devices attached to
them. 

This information is useful for 
* the user who wants to find out to what high-level interfaces the SCSI 
  devices in /proc/scsi/scsi list
* userspace tools that want to collect information about the SCSI devices
  in order to provide persistent device naming and need to use the 
  corresponding sg devices for this.
  In case the admin ensures the stability of the CBTU nexus, the included
  script is even enough to provide persistent naming.
* allowing boot=/dev/scsi/sdcXbXtXuXpX parameter (even without devfs),
  extra patch required, will be send by separate mail
* reporting major:minor pairs to userspace for dynamic device allocation
  that's needed to support > 128 disks.

garloff@pckurt:~ $ cat /proc/scsi/map
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

Compared to the patch against 2.4.19-pre10, which has been discussed on
LKML, I removed the header line from the map file and added a text file
documenting the format of /proc/scsi/map.

The patch has been ported to 2.5 by Andries Brouwer. I have removed most 
of his formatting cleanups (to unrelated code in the same files) that he
has done. Doug Gilbert has given a lot of useful feedback. Thx!

Please apply!

diff -uNr linux-2.5.23-dj2/Documentation/scsi-devs.sh linux-2.5.23-dj2-scsimap/Documentation/scsi-devs.sh
--- linux-2.5.23-dj2/Documentation/scsi-devs.sh	Thu Jan  1 01:00:00 1970
+++ linux-2.5.23-dj2-scsimap/Documentation/scsi-devs.sh	Fri Jun 14 22:37:11 2002
@@ -0,0 +1,154 @@
+#!/bin/bash
+# Script to create SCSI device nodes according to their physical
+# address (host controller no,bus/channel,target SCSI ID,unit SCSI LUN)
+# using the /proc/scsi/map introduced in Linux 2.4.20pre/2.5.2x
+# (c) Kurt Garloff <garloff@suse.de>, 2002-06-13
+# License: GNU GPL v2
+
+# Settings
+
+# Target directory for device nodes/links
+TDIR=/dev/scsi
+
+# Make symbolic links or create fresh nodes in $TDIR
+# For link mode, the dev nodes will still be made if needed
+MODE=
+
+# In link mode, where is the real /dev dir ?
+DEVDIR=..
+
+# Ownership and permissions of newly created device nodes
+OWNER="root.disk"
+PERM="0660"
+SDIRPERM="0755"
+
+# Make scsi disk partitions (0 = off)
+SDPART=15
+
+# End of settings
+
+# Options
+# -f: Remove all old devs
+if test "$1" = "-f"; then
+  rm -f $TDIR/*
+  shift
+fi
+# -l: Make links 
+if test "$1" = "-l"; then
+  MODE=LINK
+  shift
+fi
+
+# Sanitize environment
+export LANG=posix
+unset IFS
+#umask `printf %o $[0777-$PERM]`
+PATH=/bin:/usr/bin:/sbin:/usr/sbin
+
+# Functions
+function exit_fail 
+{
+  echo $1
+  exit $2
+}
+
+# Build new scsi name based on oldname (prefix) and 
+# append host,channel,id,lun numbers that are unique
+# and persistent identifiers for the device.
+function builddevnm
+{ 
+  if test "${5:0:2}" = "sd"; then
+    NM="sdc$1b$2t${3#0}u${4#0}"
+  else
+    NM="${5%%[0-9]*}c$1b$2t${3#0}u${4#0}"
+  fi
+}
+
+# Make device node
+# Parameters filename type maj(hex) min(hex) minadd(dec)
+function mk_nod
+{
+  rm -f $1
+  mknod -m $PERM $1 $2 $[0x$3] $[0x$4+$5]
+  chown $OWNER $1
+}
+
+# Make device by creating node or symlinking
+# Parameters oldname device(tp:maj:min) newname minadd
+function mk_dev 
+{
+  IFS=":"
+  if test "$MODE" = "LINK"; then
+    if test ! -e $TDIR/$DEVDIR/$1; then
+      mk_nod $TDIR/$DEVDIR/$1 $2 $4
+    fi
+    ln -sf $DEVDIR/$1 $TDIR/$3
+  else
+    mk_nod $TDIR/$3 $2 $4
+  fi
+  unset IFS
+}
+
+# Make multiple devices in case we do have sd partitions
+# Parameters oldname device(tp:maj:min) newname
+function mk_devs
+{
+  mk_dev $1 $2 $3 0
+  # Handle partitions
+  if test "${1:0:2}" = "sd" -a "$SDPART" != "0"; then
+    #unset IFS
+    for no in `seq 1 $SDPART`; do
+      mk_dev $1$no $2 $3p$no $no
+    done
+  fi
+  # Handle nst/nosst
+  if test "${1:0:2}" = "st" -o "${1:0:4}" = "osst"; then
+    mk_dev n$1 $2 n$3 128
+  fi
+}
+
+# Main() Script
+if ! test -e /proc/scsi/map; then
+  exit_fail "/proc/scsi/map does not exist" 1
+fi
+if ! test -d $TDIR; then
+  mkdir -m $SDIRMODE $TDIR || exit_fail "Failed to create $TDIR" 2
+  chown $OWNER $TDIR
+fi
+
+# We might have been called by some sort of hotplug event
+# and are only support to add a single device
+# Syntax for this is [-l] add host channel id lun
+if test "$1" = "add"; then
+  CMPAGAINST="$2,$3,`printf %02i $4`,`printf %02i $5`"
+else
+  unset CMPAGAINST
+fi
+# The main processing loop
+while read cbtu tp onl sgnm sgdev othnm othdev oothnm oothdev rest; do
+  # Skip comment line(s)
+  if test "${cbtu:0:1}" = "#"; then continue; fi
+  # If we're just dealing with one device, do skip the others
+  if test ! -z "$CMPAGAINST" -a "$CMPAGAINST" != "$cbtu"; then continue; fi
+  # now parse line
+  IFS=","
+  # Test for validity of sg device
+  if test "$sgnm" != "sg?"; then
+    builddevnm $cbtu $sgnm
+    mk_dev $sgnm $sgdev $NM 0
+  fi
+  # There is possibly a second device
+  if test ! -z "$othnm" -a ! "$othnm" = "none"; then
+    IFS=","
+    builddevnm $cbtu $othnm
+    mk_devs $othnm $othdev $NM
+    # Maybe even a third one
+    if test ! -z "$oothnm" -a ! "$oothnm" = "none"; then
+      IFS=","
+      builddevnm $cbtu $oothnm
+      mk_devs $oothnm $oothdev $NM
+    fi
+  fi
+  unset IFS
+done < /proc/scsi/map
+
diff -uNr linux-2.5.23-dj2/Documentation/scsi-map.txt linux-2.5.23-dj2-scsimap/Documentation/scsi-map.txt
--- linux-2.5.23-dj2/Documentation/scsi-map.txt	Thu Jan  1 01:00:00 1970
+++ linux-2.5.23-dj2-scsimap/Documentation/scsi-map.txt	Wed Jun 19 18:58:30 2002
@@ -0,0 +1,61 @@
+/proc/scsi/map file format
+==========================
+The file /proc/scsi/map reports the mapping of SCSI devices to high-level
+drivers (sg,sr,sd,st,osst) in Linux. The SCSI devices are identified by
+Controller/host number, bus/channel number, SCSI Target ID and SCSI Unit/LUN
+number.
+
+The output looks as following:
+
+garloff@pckurt:/raid5/Kernel $ head -18 /proc/scsi/map 
+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
+
+The format contains a variable number of columns, separated by a TAB '\t'
+character.
+
+1st column: The Controller, Bus, Target, Unit (or call it Host, Channel, ID,
+            LUN) tuple that identifies a SCSI device. The numbers are all
+	    in decimal format and separated by commas.
+2nd column: Device type as reported in the peripheral device type field
+	    as reported by SCSI INQUIRY. Hexadecimal.
+3rd column: Flag whether the device is online.
+
+These columns are followed by pairs of columns, depending on how many
+high-level drivers are attached to the device:
+
+Nth column: Driver name with an index attached. This coïncides with the old
+	    style device naming used on SCSI distributions and documented
+	    in devices.txt. For disks, therefore the index is composed of
+	    characters to produce the names sda ... sdz, sdaa ... sdaz,
+	    sdba ... etc.
+(N+1)th c.: Device node that belongs to this device. First character is
+	    identifying whether we deal with a character device (c) or a 
+	    block device(b). The major and minor numbers follow in hexa-
+	    decimal formast, separated with colons (:).
+
+The sg devices are reported first.
+If there is no sg device, sg? c:NN:NN will be reported.
+For the other devices the columns are just left empty.
+
+The reason for this special ahndling of sg is that sg is special in
+that it can drive all devices and can be used by userspace tools 
+to inquire extra information (by sending SCSI commands or doing ioctls) 
+in order to provide persistent device naming.
+
+Note that only loaded drivers (modules) can attach to the devices, so
+you e.g. won't see "sr" output, unless you have the sr driver compiled 
+into your kernel or loaded as module.
+
+				Kurt Garloff <garloff@suse.de>, 2002-06-19
diff -uNr linux-2.5.23-dj2/drivers/scsi/hosts.h linux-2.5.23-dj2-scsimap/drivers/scsi/hosts.h
--- linux-2.5.23-dj2/drivers/scsi/hosts.h	Thu Jun 20 01:44:47 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/hosts.h	Thu Jun 20 02:03:21 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.23-dj2/drivers/scsi/osst.c linux-2.5.23-dj2-scsimap/drivers/scsi/osst.c
--- linux-2.5.23-dj2/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/osst.c	Thu Jun 20 02:03:21 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi.c linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.c
--- linux-2.5.23-dj2/drivers/scsi/scsi.c	Wed Jun 19 04:11:55 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.c	Thu Jun 20 02:06:34 2002
@@ -78,6 +78,7 @@
 
 #ifdef CONFIG_PROC_FS
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length);
+static int scsi_proc_map (char *buffer, char **start, off_t offset, int length);
 static void scsi_dump_status(int level);
 #endif
 
@@ -1545,6 +1546,71 @@
 }
 
 #ifdef CONFIG_PROC_FS
+/* 
+ * Output the mapping of physical devices (contorller,channel.id,lun)
+ * to devices (sg and other highlevel drivers) to /proc/scsi/map.
+ * Caveat: No locking is done, so if your scsi config changes during
+ * reading this file, you may read garbled data.	KG, 2002-06-14
+ */
+static int scsi_proc_map(char *buffer, char **start, off_t offset, int length)
+{
+	Scsi_Device *scd;
+	struct Scsi_Host *HBA_ptr;
+	int size = 0, len = 0;
+	off_t begin = 0;
+	off_t pos = 0;
+#ifdef CONFIG_KMOD
+	int repeat = 0;
+#endif
+
+	struct Scsi_Device_Template *sg_t;
+	do {
+		sg_t = scsi_devicelist;
+		while (sg_t && !(sg_t->tag && !strcmp(sg_t->tag, "sg")))
+			sg_t = sg_t->next;
+#ifdef CONFIG_KMOD
+		if (!repeat && !sg_t)
+			request_module("sg");
+	} while (!repeat++);
+#else
+	} while (0);
+#endif	
+	/*
+	 * First, see if there are any attached devices or not.
+	 */
+	for (HBA_ptr = scsi_hostlist; HBA_ptr; HBA_ptr = HBA_ptr->next) {
+		if (HBA_ptr->host_queue != NULL) {
+			break;
+		}
+	}
+	if (!HBA_ptr)
+		goto stop_map_output;
+	
+	pos = begin;
+
+	for (HBA_ptr = scsi_hostlist; HBA_ptr; HBA_ptr = HBA_ptr->next) {
+		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
+			proc_print_scsimap(scd, buffer, &size, len, sg_t);
+			len += size;
+			pos = begin + len;
+
+			if (pos < offset) {
+				len = 0;
+				begin = pos;
+			}
+			if (pos > offset + length)
+				goto stop_map_output;
+		}
+	}
+
+ stop_map_output:
+	*start = buffer + (offset - begin);	/* Start of wanted data */
+	len -= (offset - begin);	/* Start slop */
+	if (len > length)
+		len = length;	/* Ending slop */
+	return (len);
+}
+
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length)
 {
 	Scsi_Device *scd;
@@ -2505,6 +2571,7 @@
 static int __init init_scsi(void)
 {
 	struct proc_dir_entry *generic;
+	struct proc_dir_entry *map;
 	int i;
 
 	printk(KERN_INFO "SCSI subsystem driver " REVISION "\n");
@@ -2541,6 +2608,13 @@
 		return -ENOMEM;
 	}
 	generic->write_proc = proc_scsi_gen_write;
+	
+	map = create_proc_info_entry ("scsi/map", 0, 0, scsi_proc_map);
+	if (!map) {
+		printk (KERN_ERR "cannot init /proc/scsi/map\n");
+		remove_proc_entry("scsi", 0);
+		return -ENOMEM;
+	}
 #endif
 
         scsi_devfs_handle = devfs_mk_dir (NULL, "scsi", NULL);
@@ -2571,6 +2645,7 @@
 
 #ifdef CONFIG_PROC_FS
 	/* No, we're not here anymore. Don't show the /proc/scsi files. */
+	remove_proc_entry ("scsi/map", 0);
 	remove_proc_entry ("scsi/scsi", 0);
 	remove_proc_entry ("scsi", 0);
 #endif
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi.h linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.h
--- linux-2.5.23-dj2/drivers/scsi/scsi.h	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.h	Thu Jun 20 02:03:21 2002
@@ -523,6 +523,8 @@
  * Prototypes for functions in scsi_proc.c
  */
 extern void proc_print_scsidevice(Scsi_Device *, char *, int *, int);
+extern void proc_print_scsimap(Scsi_Device *, char *, int *, int, 
+			       struct Scsi_Device_Template *);
 extern struct proc_dir_entry *proc_scsi;
 
 /*
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi_proc.c linux-2.5.23-dj2-scsimap/drivers/scsi/scsi_proc.c
--- linux-2.5.23-dj2/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi_proc.c	Thu Jun 20 02:03:21 2002
@@ -300,29 +301,54 @@
 	return;
 }
 
+
+void proc_print_scsimap(Scsi_Device *scd, char *buffer, int *size, int len,
+			struct Scsi_Device_Template *sg_t)
+{
+	int y, err;
+	char nm[16];
+	kdev_t kdev; 
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
+
+	y = sprintf(buffer + len,
+	     "%i,%i,%02i,%02i\t0x%02x\t%i",
+		    scd->host->host_no, scd->channel, scd->id, scd->lun,
+		    scd->type, scd->online);
+	if (sg_t && sg_t->find_kdev && !(sg_t->find_kdev(scd, nm, &kdev))) {
+		y += sprintf(buffer + len + y,
+			     "\t%s\tc:%02x:%02x",
+			     nm, major(kdev), minor(kdev));
+		--att;
+	} else {
+		y += sprintf(buffer + len + y,
+			     "\tsg?\tc:NN:NN");
+	}
+	while (att && sd_t) {
+		if (sd_t->scsi_type != 0xff && sd_t->find_kdev) {
+			err = sd_t->find_kdev(scd, nm, &kdev);
+			if (!err) {
+				y += sprintf(buffer + len + y,
+					     "\t%s\t%c:%02x:%02x",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     major(kdev), minor(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
+	*size = y;
+}
+
 #else				/* if !CONFIG_PROC_FS */
 
 void proc_print_scsidevice(Scsi_Device * scd, char *buffer, int *size, int len)
 {
 }
+void proc_print_scsimap(Scsi_Device *scd, char *buffer, int *size, int len)
+{
+}
 
 #endif				/* CONFIG_PROC_FS */
-
-/*
- * Overrides for Emacs so that we get a uniform tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-indent-level: 4
- * c-brace-imaginary-offset: 0
- * c-brace-offset: -4
- * c-argdecl-indent: 4
- * c-label-offset: -4
- * c-continued-statement-offset: 4
- * c-continued-brace-offset: 0
- * indent-tabs-mode: nil
- * tab-width: 8
- * End:
- */
diff -uNr linux-2.5.23-dj2/drivers/scsi/sd.c linux-2.5.23-dj2-scsimap/drivers/scsi/sd.c
--- linux-2.5.23-dj2/drivers/scsi/sd.c	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sd.c	Thu Jun 20 02:03:21 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.23-dj2/drivers/scsi/sg.c linux-2.5.23-dj2-scsimap/drivers/scsi/sg.c
--- linux-2.5.23-dj2/drivers/scsi/sg.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sg.c	Thu Jun 20 02:03:21 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2632,6 +2635,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.23-dj2/drivers/scsi/sr.c linux-2.5.23-dj2-scsimap/drivers/scsi/sr.c
--- linux-2.5.23-dj2/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sr.c	Thu Jun 20 02:03:21 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.23-dj2/drivers/scsi/st.c linux-2.5.23-dj2-scsimap/drivers/scsi/st.c
--- linux-2.5.23-dj2/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/st.c	Thu Jun 20 02:03:21 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();


-- 
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-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] /proc/scsi/map

[Kurt Garloff]

Hi Linus,

find attached a patch (against 2.5.23-dj2) to the SCSI subsystem which 
adds a file /proc/scsi/map, which provides a listing of SCSI devices,
enumerated by the CBTU/HCIL tuple and the high-level devices attached to
them. 

This information is useful for 
* the user who wants to find out to what high-level interfaces the SCSI 
  devices in /proc/scsi/scsi list
* userspace tools that want to collect information about the SCSI devices
  in order to provide persistent device naming and need to use the 
  corresponding sg devices for this.
  In case the admin ensures the stability of the CBTU nexus, the included
  script is even enough to provide persistent naming.
* allowing boot=/dev/scsi/sdcXbXtXuXpX parameter (even without devfs),
  extra patch required, will be send by separate mail
* reporting major:minor pairs to userspace for dynamic device allocation
  that's needed to support > 128 disks.

garloff@pckurt:~ $ cat /proc/scsi/map
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

Compared to the patch against 2.4.19-pre10, which has been discussed on
LKML, I removed the header line from the map file and added a text file
documenting the format of /proc/scsi/map.

The patch has been ported to 2.5 by Andries Brouwer. I have removed most 
of his formatting cleanups (to unrelated code in the same files) that he
has done. Doug Gilbert has given a lot of useful feedback. Thx!

Please apply!

diff -uNr linux-2.5.23-dj2/Documentation/scsi-devs.sh linux-2.5.23-dj2-scsimap/Documentation/scsi-devs.sh
--- linux-2.5.23-dj2/Documentation/scsi-devs.sh	Thu Jan  1 01:00:00 1970
+++ linux-2.5.23-dj2-scsimap/Documentation/scsi-devs.sh	Fri Jun 14 22:37:11 2002
@@ -0,0 +1,154 @@
+#!/bin/bash
+# Script to create SCSI device nodes according to their physical
+# address (host controller no,bus/channel,target SCSI ID,unit SCSI LUN)
+# using the /proc/scsi/map introduced in Linux 2.4.20pre/2.5.2x
+# (c) Kurt Garloff <garloff@suse.de>, 2002-06-13
+# License: GNU GPL v2
+
+# Settings
+
+# Target directory for device nodes/links
+TDIR=/dev/scsi
+
+# Make symbolic links or create fresh nodes in $TDIR
+# For link mode, the dev nodes will still be made if needed
+MODE=
+
+# In link mode, where is the real /dev dir ?
+DEVDIR=..
+
+# Ownership and permissions of newly created device nodes
+OWNER="root.disk"
+PERM="0660"
+SDIRPERM="0755"
+
+# Make scsi disk partitions (0 = off)
+SDPART=15
+
+# End of settings
+
+# Options
+# -f: Remove all old devs
+if test "$1" = "-f"; then
+  rm -f $TDIR/*
+  shift
+fi
+# -l: Make links 
+if test "$1" = "-l"; then
+  MODE=LINK
+  shift
+fi
+
+# Sanitize environment
+export LANG=posix
+unset IFS
+#umask `printf %o $[0777-$PERM]`
+PATH=/bin:/usr/bin:/sbin:/usr/sbin
+
+# Functions
+function exit_fail 
+{
+  echo $1
+  exit $2
+}
+
+# Build new scsi name based on oldname (prefix) and 
+# append host,channel,id,lun numbers that are unique
+# and persistent identifiers for the device.
+function builddevnm
+{ 
+  if test "${5:0:2}" = "sd"; then
+    NM="sdc$1b$2t${3#0}u${4#0}"
+  else
+    NM="${5%%[0-9]*}c$1b$2t${3#0}u${4#0}"
+  fi
+}
+
+# Make device node
+# Parameters filename type maj(hex) min(hex) minadd(dec)
+function mk_nod
+{
+  rm -f $1
+  mknod -m $PERM $1 $2 $[0x$3] $[0x$4+$5]
+  chown $OWNER $1
+}
+
+# Make device by creating node or symlinking
+# Parameters oldname device(tp:maj:min) newname minadd
+function mk_dev 
+{
+  IFS=":"
+  if test "$MODE" = "LINK"; then
+    if test ! -e $TDIR/$DEVDIR/$1; then
+      mk_nod $TDIR/$DEVDIR/$1 $2 $4
+    fi
+    ln -sf $DEVDIR/$1 $TDIR/$3
+  else
+    mk_nod $TDIR/$3 $2 $4
+  fi
+  unset IFS
+}
+
+# Make multiple devices in case we do have sd partitions
+# Parameters oldname device(tp:maj:min) newname
+function mk_devs
+{
+  mk_dev $1 $2 $3 0
+  # Handle partitions
+  if test "${1:0:2}" = "sd" -a "$SDPART" != "0"; then
+    #unset IFS
+    for no in `seq 1 $SDPART`; do
+      mk_dev $1$no $2 $3p$no $no
+    done
+  fi
+  # Handle nst/nosst
+  if test "${1:0:2}" = "st" -o "${1:0:4}" = "osst"; then
+    mk_dev n$1 $2 n$3 128
+  fi
+}
+
+# Main() Script
+if ! test -e /proc/scsi/map; then
+  exit_fail "/proc/scsi/map does not exist" 1
+fi
+if ! test -d $TDIR; then
+  mkdir -m $SDIRMODE $TDIR || exit_fail "Failed to create $TDIR" 2
+  chown $OWNER $TDIR
+fi
+
+# We might have been called by some sort of hotplug event
+# and are only support to add a single device
+# Syntax for this is [-l] add host channel id lun
+if test "$1" = "add"; then
+  CMPAGAINST="$2,$3,`printf %02i $4`,`printf %02i $5`"
+else
+  unset CMPAGAINST
+fi
+# The main processing loop
+while read cbtu tp onl sgnm sgdev othnm othdev oothnm oothdev rest; do
+  # Skip comment line(s)
+  if test "${cbtu:0:1}" = "#"; then continue; fi
+  # If we're just dealing with one device, do skip the others
+  if test ! -z "$CMPAGAINST" -a "$CMPAGAINST" != "$cbtu"; then continue; fi
+  # now parse line
+  IFS=","
+  # Test for validity of sg device
+  if test "$sgnm" != "sg?"; then
+    builddevnm $cbtu $sgnm
+    mk_dev $sgnm $sgdev $NM 0
+  fi
+  # There is possibly a second device
+  if test ! -z "$othnm" -a ! "$othnm" = "none"; then
+    IFS=","
+    builddevnm $cbtu $othnm
+    mk_devs $othnm $othdev $NM
+    # Maybe even a third one
+    if test ! -z "$oothnm" -a ! "$oothnm" = "none"; then
+      IFS=","
+      builddevnm $cbtu $oothnm
+      mk_devs $oothnm $oothdev $NM
+    fi
+  fi
+  unset IFS
+done < /proc/scsi/map
+
diff -uNr linux-2.5.23-dj2/Documentation/scsi-map.txt linux-2.5.23-dj2-scsimap/Documentation/scsi-map.txt
--- linux-2.5.23-dj2/Documentation/scsi-map.txt	Thu Jan  1 01:00:00 1970
+++ linux-2.5.23-dj2-scsimap/Documentation/scsi-map.txt	Wed Jun 19 18:58:30 2002
@@ -0,0 +1,61 @@
+/proc/scsi/map file format
+==========================
+The file /proc/scsi/map reports the mapping of SCSI devices to high-level
+drivers (sg,sr,sd,st,osst) in Linux. The SCSI devices are identified by
+Controller/host number, bus/channel number, SCSI Target ID and SCSI Unit/LUN
+number.
+
+The output looks as following:
+
+garloff@pckurt:/raid5/Kernel $ head -18 /proc/scsi/map 
+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
+
+The format contains a variable number of columns, separated by a TAB '\t'
+character.
+
+1st column: The Controller, Bus, Target, Unit (or call it Host, Channel, ID,
+            LUN) tuple that identifies a SCSI device. The numbers are all
+	    in decimal format and separated by commas.
+2nd column: Device type as reported in the peripheral device type field
+	    as reported by SCSI INQUIRY. Hexadecimal.
+3rd column: Flag whether the device is online.
+
+These columns are followed by pairs of columns, depending on how many
+high-level drivers are attached to the device:
+
+Nth column: Driver name with an index attached. This coïncides with the old
+	    style device naming used on SCSI distributions and documented
+	    in devices.txt. For disks, therefore the index is composed of
+	    characters to produce the names sda ... sdz, sdaa ... sdaz,
+	    sdba ... etc.
+(N+1)th c.: Device node that belongs to this device. First character is
+	    identifying whether we deal with a character device (c) or a 
+	    block device(b). The major and minor numbers follow in hexa-
+	    decimal formast, separated with colons (:).
+
+The sg devices are reported first.
+If there is no sg device, sg? c:NN:NN will be reported.
+For the other devices the columns are just left empty.
+
+The reason for this special ahndling of sg is that sg is special in
+that it can drive all devices and can be used by userspace tools 
+to inquire extra information (by sending SCSI commands or doing ioctls) 
+in order to provide persistent device naming.
+
+Note that only loaded drivers (modules) can attach to the devices, so
+you e.g. won't see "sr" output, unless you have the sr driver compiled 
+into your kernel or loaded as module.
+
+				Kurt Garloff <garloff@suse.de>, 2002-06-19
diff -uNr linux-2.5.23-dj2/drivers/scsi/hosts.h linux-2.5.23-dj2-scsimap/drivers/scsi/hosts.h
--- linux-2.5.23-dj2/drivers/scsi/hosts.h	Thu Jun 20 01:44:47 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/hosts.h	Thu Jun 20 02:03:21 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.23-dj2/drivers/scsi/osst.c linux-2.5.23-dj2-scsimap/drivers/scsi/osst.c
--- linux-2.5.23-dj2/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/osst.c	Thu Jun 20 02:03:21 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi.c linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.c
--- linux-2.5.23-dj2/drivers/scsi/scsi.c	Wed Jun 19 04:11:55 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.c	Thu Jun 20 02:06:34 2002
@@ -78,6 +78,7 @@
 
 #ifdef CONFIG_PROC_FS
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length);
+static int scsi_proc_map (char *buffer, char **start, off_t offset, int length);
 static void scsi_dump_status(int level);
 #endif
 
@@ -1545,6 +1546,71 @@
 }
 
 #ifdef CONFIG_PROC_FS
+/* 
+ * Output the mapping of physical devices (contorller,channel.id,lun)
+ * to devices (sg and other highlevel drivers) to /proc/scsi/map.
+ * Caveat: No locking is done, so if your scsi config changes during
+ * reading this file, you may read garbled data.	KG, 2002-06-14
+ */
+static int scsi_proc_map(char *buffer, char **start, off_t offset, int length)
+{
+	Scsi_Device *scd;
+	struct Scsi_Host *HBA_ptr;
+	int size = 0, len = 0;
+	off_t begin = 0;
+	off_t pos = 0;
+#ifdef CONFIG_KMOD
+	int repeat = 0;
+#endif
+
+	struct Scsi_Device_Template *sg_t;
+	do {
+		sg_t = scsi_devicelist;
+		while (sg_t && !(sg_t->tag && !strcmp(sg_t->tag, "sg")))
+			sg_t = sg_t->next;
+#ifdef CONFIG_KMOD
+		if (!repeat && !sg_t)
+			request_module("sg");
+	} while (!repeat++);
+#else
+	} while (0);
+#endif	
+	/*
+	 * First, see if there are any attached devices or not.
+	 */
+	for (HBA_ptr = scsi_hostlist; HBA_ptr; HBA_ptr = HBA_ptr->next) {
+		if (HBA_ptr->host_queue != NULL) {
+			break;
+		}
+	}
+	if (!HBA_ptr)
+		goto stop_map_output;
+	
+	pos = begin;
+
+	for (HBA_ptr = scsi_hostlist; HBA_ptr; HBA_ptr = HBA_ptr->next) {
+		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
+			proc_print_scsimap(scd, buffer, &size, len, sg_t);
+			len += size;
+			pos = begin + len;
+
+			if (pos < offset) {
+				len = 0;
+				begin = pos;
+			}
+			if (pos > offset + length)
+				goto stop_map_output;
+		}
+	}
+
+ stop_map_output:
+	*start = buffer + (offset - begin);	/* Start of wanted data */
+	len -= (offset - begin);	/* Start slop */
+	if (len > length)
+		len = length;	/* Ending slop */
+	return (len);
+}
+
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length)
 {
 	Scsi_Device *scd;
@@ -2505,6 +2571,7 @@
 static int __init init_scsi(void)
 {
 	struct proc_dir_entry *generic;
+	struct proc_dir_entry *map;
 	int i;
 
 	printk(KERN_INFO "SCSI subsystem driver " REVISION "\n");
@@ -2541,6 +2608,13 @@
 		return -ENOMEM;
 	}
 	generic->write_proc = proc_scsi_gen_write;
+	
+	map = create_proc_info_entry ("scsi/map", 0, 0, scsi_proc_map);
+	if (!map) {
+		printk (KERN_ERR "cannot init /proc/scsi/map\n");
+		remove_proc_entry("scsi", 0);
+		return -ENOMEM;
+	}
 #endif
 
         scsi_devfs_handle = devfs_mk_dir (NULL, "scsi", NULL);
@@ -2571,6 +2645,7 @@
 
 #ifdef CONFIG_PROC_FS
 	/* No, we're not here anymore. Don't show the /proc/scsi files. */
+	remove_proc_entry ("scsi/map", 0);
 	remove_proc_entry ("scsi/scsi", 0);
 	remove_proc_entry ("scsi", 0);
 #endif
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi.h linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.h
--- linux-2.5.23-dj2/drivers/scsi/scsi.h	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi.h	Thu Jun 20 02:03:21 2002
@@ -523,6 +523,8 @@
  * Prototypes for functions in scsi_proc.c
  */
 extern void proc_print_scsidevice(Scsi_Device *, char *, int *, int);
+extern void proc_print_scsimap(Scsi_Device *, char *, int *, int, 
+			       struct Scsi_Device_Template *);
 extern struct proc_dir_entry *proc_scsi;
 
 /*
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi_proc.c linux-2.5.23-dj2-scsimap/drivers/scsi/scsi_proc.c
--- linux-2.5.23-dj2/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/scsi_proc.c	Thu Jun 20 02:03:21 2002
@@ -300,29 +301,54 @@
 	return;
 }
 
+
+void proc_print_scsimap(Scsi_Device *scd, char *buffer, int *size, int len,
+			struct Scsi_Device_Template *sg_t)
+{
+	int y, err;
+	char nm[16];
+	kdev_t kdev; 
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
+
+	y = sprintf(buffer + len,
+	     "%i,%i,%02i,%02i\t0x%02x\t%i",
+		    scd->host->host_no, scd->channel, scd->id, scd->lun,
+		    scd->type, scd->online);
+	if (sg_t && sg_t->find_kdev && !(sg_t->find_kdev(scd, nm, &kdev))) {
+		y += sprintf(buffer + len + y,
+			     "\t%s\tc:%02x:%02x",
+			     nm, major(kdev), minor(kdev));
+		--att;
+	} else {
+		y += sprintf(buffer + len + y,
+			     "\tsg?\tc:NN:NN");
+	}
+	while (att && sd_t) {
+		if (sd_t->scsi_type != 0xff && sd_t->find_kdev) {
+			err = sd_t->find_kdev(scd, nm, &kdev);
+			if (!err) {
+				y += sprintf(buffer + len + y,
+					     "\t%s\t%c:%02x:%02x",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     major(kdev), minor(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
+	*size = y;
+}
+
 #else				/* if !CONFIG_PROC_FS */
 
 void proc_print_scsidevice(Scsi_Device * scd, char *buffer, int *size, int len)
 {
 }
+void proc_print_scsimap(Scsi_Device *scd, char *buffer, int *size, int len)
+{
+}
 
 #endif				/* CONFIG_PROC_FS */
-
-/*
- * Overrides for Emacs so that we get a uniform tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---------------------------------------------------------------------------
- * Local variables:
- * c-indent-level: 4
- * c-brace-imaginary-offset: 0
- * c-brace-offset: -4
- * c-argdecl-indent: 4
- * c-label-offset: -4
- * c-continued-statement-offset: 4
- * c-continued-brace-offset: 0
- * indent-tabs-mode: nil
- * tab-width: 8
- * End:
- */
diff -uNr linux-2.5.23-dj2/drivers/scsi/sd.c linux-2.5.23-dj2-scsimap/drivers/scsi/sd.c
--- linux-2.5.23-dj2/drivers/scsi/sd.c	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sd.c	Thu Jun 20 02:03:21 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.23-dj2/drivers/scsi/sg.c linux-2.5.23-dj2-scsimap/drivers/scsi/sg.c
--- linux-2.5.23-dj2/drivers/scsi/sg.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sg.c	Thu Jun 20 02:03:21 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2632,6 +2635,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.23-dj2/drivers/scsi/sr.c linux-2.5.23-dj2-scsimap/drivers/scsi/sr.c
--- linux-2.5.23-dj2/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/sr.c	Thu Jun 20 02:03:21 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.23-dj2/drivers/scsi/st.c linux-2.5.23-dj2-scsimap/drivers/scsi/st.c
--- linux-2.5.23-dj2/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.23-dj2-scsimap/drivers/scsi/st.c	Thu Jun 20 02:03:21 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();


-- 
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.)

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Kurt Garloff wrote:
> 
> find attached a patch (against 2.5.23-dj2) to the SCSI subsystem which 
> adds a file /proc/scsi/map, which provides a listing of SCSI devices,
> enumerated by the CBTU/HCIL tuple and the high-level devices attached to
> them. 

I really despise this.

Sorry.

Can't you add the SCSI devices to the device tree, and be done with it? 

It's just _wrong_ to have one file with a collection of devices in it, and 
it is _doubly_ wrong when that one file

 - is limited to a (arbitrary) subset of the disks in your system

 - has completely bogus information about "location" that has nothing to 
   do with real life, yet pruports to be an "address" even though it 
   obviously isn't.

> +The format contains a variable number of columns, separated by a TAB '\t'
> +character.
> +
> +1st column: The Controller, Bus, Target, Unit (or call it Host, Channel, ID,
> +            LUN) tuple that identifies a SCSI device. The numbers are all
> +	    in decimal format and separated by commas.

These "addresses" are not addresses at all. They have no bearing on where 
the card is, will change if a host is added, yadda yadda.

All fixed at least to _some_ degree by giving the most complete address we 
can, ie something like

	/devices/root/pci0/00:02.0/02:1f.0/03:07.0

And yes, the above is a _real_ example, that exists today: it's my SCSI 
controller, and it's behind _two_ PCI bridges. 

Is is also "scsi controller 0"? Yes. But that's a meaningless thing, and 
should not matter.

Either you enumerate things without any structure (like the current SCSI
layer does: disk0, disk1, disk2 ...) or you give full their addresses.  
Don't do the half-assed thing.

PLEASE don't add these kinds of SCSI-specific hacks, that are _useless_ to
find other types of disks, and that makes no sense, and will not work for
things like DAC960, for IDE, or for anything else that just ignores the 
SCSI layer (even if it physically uses SCSI disks, like the DAC960 setup).

			Linus

Re: [PATCH] /proc/scsi/map

[Martin Schwenke]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> Can't you add the SCSI devices to the device tree, and be
    Linus> done with it? 

Do you mean the /devices tree or the Open Firmware (OF) device-tree
(as in IEEE Std 1275).  I suspect that you mean the former, but...

    Linus> [...]

    Linus> All fixed at least to _some_ degree by giving the most
    Linus> complete address we can, ie something like

    Linus> 	/devices/root/pci0/00:02.0/02:1f.0/03:07.0

That looks similar, but not identical to an Open Firmware node for a
SCSI device:

  device-tree/pci@3fff5e09000/pci@b,6/scsi@1,1/sd/...

Why not use the structure of, and a subset of the capabilities of, an
OF device-tree for building /devices?  It's a little more verbose, but
it's a standard and it fits the current problem pretty well.

I've been working on some hardware inventory stuff at IBM that uses an
augmented OF device-tree (as a directory tree in userspace) to keep
track of useful stuff...

peace & happiness,
martin

Re: [PATCH] /proc/scsi/map

[Martin Schwenke]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> Can't you add the SCSI devices to the device tree, and be
    Linus> done with it? 

Do you mean the /devices tree or the Open Firmware (OF) device-tree
(as in IEEE Std 1275).  I suspect that you mean the former, but...

    Linus> [...]

    Linus> All fixed at least to _some_ degree by giving the most
    Linus> complete address we can, ie something like

    Linus> 	/devices/root/pci0/00:02.0/02:1f.0/03:07.0

That looks similar, but not identical to an Open Firmware node for a
SCSI device:

  device-tree/pci@3fff5e09000/pci@b,6/scsi@1,1/sd/...

Why not use the structure of, and a subset of the capabilities of, an
OF device-tree for building /devices?  It's a little more verbose, but
it's a standard and it fits the current problem pretty well.

I've been working on some hardware inventory stuff at IBM that uses an
augmented OF device-tree (as a directory tree in userspace) to keep
track of useful stuff...

peace & happiness,
martin

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Martin Schwenke wrote:
>
> Do you mean the /devices tree or the Open Firmware (OF) device-tree
> (as in IEEE Std 1275).  I suspect that you mean the former, but...

The "struct device" tree that is already built up by

>
>     Linus> [...]
>
>     Linus> All fixed at least to _some_ degree by giving the most
>     Linus> complete address we can, ie something like
>
>     Linus> 	/devices/root/pci0/00:02.0/02:1f.0/03:07.0
>
> That looks similar, but not identical to an Open Firmware node for a
> SCSI device:
>
>   device-tree/pci@3fff5e09000/pci@b,6/scsi@1,1/sd/...

Try it out yourself. Just do

	mount -t driverfs /devices /devices

and then look at the whole glory in some graphical file manager to get a
view of the tree (actually, most file managers are somewhat confused about
the fact that the directory counts don't reflect sub-directories, so you
may have to open the subdirectories by hand, whatever. That's a bug.
Should be fixed. I'm cc'ing Pat)

> Why not use the structure of, and a subset of the capabilities of, an
> OF device-tree for building /devices?  It's a little more verbose, but
> it's a standard and it fits the current problem pretty well.

Because an OF devices tree has nothing to do with Linux?

Open Firmware is dead, dead, dead. It's not sleeping. It's an ex-standard.
Intel and the PC market never bought into it, so it doesn't exist.

End result: Linux has a notion of a "struct device", and it's an internal
kernel representation of the whole bus structure as far as Linux can tell.
It's then exported as a filesystem, but that's not the important part: the
device tree is valid (and important) even when it's not exported to user
space, simply because things like power-management events etc have to
honor the tree and traverse it in the right order.

If you like OF, you can actually use OF to _populate_ the Linux device
tree. The people who like ACPI (yet, they exist) do that with ACPI. The
Linux device tree is _completely_ agnostic, and absolutely does _not_ want
to know or depend on firmware issues, since firmware is not portable.

(Right now ACPI does this, so all the strange ACPI nodes will show up in
/devices/root/ACPI if you have ACPI enabled).

Right now you cannot do a lot with it, but it does already give you a
global view of the system - at least for those buses that use "struct
device", namely USB and PCI.

It should be possible to export _any_ bus using this. Most definitely
including SCSI.

		Linus

Re: [PATCH] /proc/scsi/map

[Dave Jones]

On Thu, Jun 20, 2002 at 08:13:22AM -0700, Linus Torvalds wrote:
 > and then look at the whole glory in some graphical file manager to get a
 > view of the tree (actually, most file managers are somewhat confused about
 > the fact that the directory counts don't reflect sub-directories, so you
 > may have to open the subdirectories by hand, whatever. That's a bug.
 > Should be fixed. I'm cc'ing Pat)

Is this the same bug that causes this wierdo..

(davej@mesh:drivers)$ pwd
/driver/bus/pci/drivers
(davej@mesh:drivers)$ ls -l
ls: VIA 82C686A/B: No such file or directory
total 0
drwxr-xr-x    1 root     root            0 Jun 19 22:34 3c59x/
drwxr-xr-x    1 root     root            0 Jun 19 22:34 Sound Fusion CS46xx/
drwxr-xr-x    1 root     root            0 Jun 19 22:34 bttv/
drwxr-xr-x    1 root     root            0 Jun 19 22:34 parport_pc/
drwxr-xr-x    1 root     root            0 Jun 19 22:34 serial/

(Note the VIA line)

        Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Dave Jones wrote:
>
> Is this the same bug that causes this wierdo..
>
> (davej@mesh:drivers)$ pwd
> /driver/bus/pci/drivers
> (davej@mesh:drivers)$ ls -l
> ls: VIA 82C686A/B: No such file or directory

No, that's a separate issue: a device that has an embedded "/" in the
filename is not something you can look up in a UNIX filesystem.

So drivers should avoid using "/" in their name.

(or driverfs might convert them automatically, although I personally think
we should just avoid them).

		Linus

Re: [PATCH] /proc/scsi/map

[Andries Brouwer]

On Thu, Jun 20, 2002 at 08:13:22AM -0700, Linus Torvalds wrote:

> Try it out yourself. Just do
> 
> 	mount -t driverfs /devices /devices
> 
> and then look at the whole glory

OK. I just did.

# find . -name name -exec cat {} ";"
...
PCI device 8086:7113
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
usb_name
PCI device 8086:7112
...

At present this does not look very useful, but it may have future.

But there is a pressing present problem. What name do my devices have?
I plug in a SmartMedia card reader. It will become some SCSI device.
But which one? The easiest way to find out is just to try
"blockdev --rereadpt /dev/sdX" for X=a,b,c,d,e to find: yes, today
this thing is /dev/sde.

Of course file system names are free, so instead of asking what sdX
this device is, I should ask what major:minor this device is.

In other words, there is the difficult naming problem,
but there is also the translation problem. The user does
not recognize the device as USB device 04e6:0005:...
She thinks of this thing as her DaneElec card reader.

So, there are many names and partial names for the same object,
and translation is required from one name to another.
>From sg names to sd names to usb names.

Kurt's patch does not solve all problems, but what it provides
is a small translation table between different names for the same thing.
That information is not easily obtainable without his patch.
I do not see that driverfs provides such information.

Andries


[And please, Linus, do not use words like "despise".
Lately I have seen an increase in the amount of insults
between Linux people. That is unnecessary.]

Re: [PATCH] /proc/scsi/map

[Andries Brouwer]

On Thu, Jun 20, 2002 at 08:13:22AM -0700, Linus Torvalds wrote:

> Try it out yourself. Just do
> 
> 	mount -t driverfs /devices /devices
> 
> and then look at the whole glory

OK. I just did.

# find . -name name -exec cat {} ";"
...
PCI device 8086:7113
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
USB device 0000:0000
figure out some name...
usb_name
PCI device 8086:7112
...

At present this does not look very useful, but it may have future.

But there is a pressing present problem. What name do my devices have?
I plug in a SmartMedia card reader. It will become some SCSI device.
But which one? The easiest way to find out is just to try
"blockdev --rereadpt /dev/sdX" for X=a,b,c,d,e to find: yes, today
this thing is /dev/sde.

Of course file system names are free, so instead of asking what sdX
this device is, I should ask what major:minor this device is.

In other words, there is the difficult naming problem,
but there is also the translation problem. The user does
not recognize the device as USB device 04e6:0005:...
She thinks of this thing as her DaneElec card reader.

So, there are many names and partial names for the same object,
and translation is required from one name to another.
>From sg names to sd names to usb names.

Kurt's patch does not solve all problems, but what it provides
is a small translation table between different names for the same thing.
That information is not easily obtainable without his patch.
I do not see that driverfs provides such information.

Andries


[And please, Linus, do not use words like "despise".
Lately I have seen an increase in the amount of insults
between Linux people. That is unnecessary.]

Re: [PATCH] /proc/scsi/map

[Patrick Mansfield]

On Thu, Jun 20, 2002 at 06:55:53PM +0200, Andries Brouwer wrote:
> Kurt's patch does not solve all problems, but what it provides
> is a small translation table between different names for the same thing.
> That information is not easily obtainable without his patch.
> I do not see that driverfs provides such information.
> 
> Andries

With Mike Sullivan'a patch for SCSI driverfs support: 

http://marc.theaimsgroup.com/?l=linux-scsi&m=102434655912858&w=2

You can see the relationship (not that it is simpile or easy to read),
for example, on my system for the LUN at scsi3 channel 0 , id 3, lun 0
I can see that the sd (disc) is at major/minor 4200 (66, 0), and sg
(gen) is at 1521 (21, 33):

[root@elm3a50 3:0:3:0]# pwd
/devices/root/pci1/01:07.0/scsi3/3:0:3:0
[root@elm3a50 3:0:3:0]# find .
.
./3:0:3:0:p2
./3:0:3:0:p2/kdev
./3:0:3:0:p2/type
./3:0:3:0:p2/power
./3:0:3:0:p2/name
./3:0:3:0:p1
./3:0:3:0:p1/kdev
./3:0:3:0:p1/type
./3:0:3:0:p1/power
./3:0:3:0:p1/name
./3:0:3:0:disc
./3:0:3:0:disc/kdev
./3:0:3:0:disc/type
./3:0:3:0:disc/power
./3:0:3:0:disc/name
./3:0:3:0:gen
./3:0:3:0:gen/kdev
./3:0:3:0:gen/type
./3:0:3:0:gen/power
./3:0:3:0:gen/name
./type
./power
./name
[root@elm3a50 3:0:3:0]# cat 3\:0\:3\:0\:gen/kdev
1521
[root@elm3a50 3:0:3:0]# cat 3\:0\:3\:0\:disc/kdev
4200
[root@elm3a50 3:0:3:0]# ls -l /dev/sdag
brw-rw----    1 root     disk      66,   0 Aug 30  2001 /dev/sdag


-- Patrick Mansfield

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Patrick Mansfield wrote:
>
> With Mike Sullivan'a patch for SCSI driverfs support:
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=102434655912858&w=2

Interesting, it does seem to set up most of the obvious stuff.

SCSI people, how does that patch look to you? Apparently it does
everything the scsimap thing does, in a way that is certainly acceptable
to me.

I personally think that the biggest problem with driverfs is it's lack of
a 2.4.x counterpart. Although the filesystem itself should be fairly easy
to port, moving around all the pci device structure members etc in order
to embed "struct device" into the PCI structure sounds like something you
definitely don't want to do in 2.4.x.

		Linus

Re: [PATCH] /proc/scsi/map

[James Bottomley]

torvalds@transmeta.com said:
> SCSI people, how does that patch look to you? Apparently it does
> everything the scsimap thing does, in a way that is certainly
> acceptable to me. 

It looks OK to me.  It doesn't quite do everything you want in terms of doing 
your bus1/id2/lun0 piece, but it's a good start.

We should probably have some more discussion about the layout of the device 
tree, particularly if it's going to be consistent with other devices like ide 
discs and cds.

I'd like to see the "name" field become mutable from user level somehow just 
so we can fix the enterprise name on broken devices without having to have a 
huge kernel exception table, but that's my only current concern.

James

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, James Bottomley wrote:
>
> We should probably have some more discussion about the layout of the device
> tree, particularly if it's going to be consistent with other devices like ide
> discs and cds.

Absolutely. I suspect that the _real_ issues start coming up only once
people start using this for useful work, and we should just accept that
the format (for now) is in flux. But that doesn't mean that we shouldn't
try to make it reasonably sane from the very start.

And make sure that the naming convention works for both IDE and SCSI (ie
there should be a way to figure out _portably_ whether a device is a disk
or CD-RW or whatever, without even knowing whether it's SCSI or IDE).

			Linus

Re: [PATCH] /proc/scsi/map

[Benjamin Herrenschmidt]

>Absolutely. I suspect that the _real_ issues start coming up only once
>people start using this for useful work, and we should just accept that
>the format (for now) is in flux. But that doesn't mean that we shouldn't
>try to make it reasonably sane from the very start.
>
>And make sure that the naming convention works for both IDE and SCSI (ie
>there should be a way to figure out _portably_ whether a device is a disk
>or CD-RW or whatever, without even knowing whether it's SCSI or IDE).

Looking at how other kind of device trees are doing (typically
Open Firmware), I beleive this can be acheived by having a "type"
node (ie. file).

Also, there are lots of good reasons to put device/driver settings as
"properties" of the device node in the device tree, which ends up having
proc-like files under each device node.
We could define some standard ones (like the device type) and provide a
simple way (proc-like) for drivers to add more properties, thus replacing
in most cases the need for ioctls.

Ben.

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Benjamin Herrenschmidt wrote:
>
> Looking at how other kind of device trees are doing (typically
> Open Firmware), I beleive this can be acheived by having a "type"
> node (ie. file).

I think you're right. Embedding types into naming makes for easy examples
of using "find /devices -name ..." to look cool, but it also likely makes
for rather cumbersome names, _and_ there are tons of devices that want to
expose multiple different capabilitites ("it's not just a floor wax, it's
a dessert topping too!").

> Also, there are lots of good reasons to put device/driver settings as
> "properties" of the device node in the device tree, which ends up having
> proc-like files under each device node.

You're bound to have multiple files under each node anyway, for things
like partition information etc. Yes.

> We could define some standard ones (like the device type) and provide a
> simple way (proc-like) for drivers to add more properties, thus replacing
> in most cases the need for ioctls.

Absolutely. The current driverfs thing does some of that (the "name"
thing, mainly useful for havign uniform naming between different tools,
and PCI devices for example all get a standard set of property files
from the bus driver).

But it should hopefully be driven by real need, not just "cool feature".
Which is always a chicken-and-egg issue, of course.

		Linus

Re: [PATCH] /proc/scsi/map

[Benjamin Herrenschmidt]

>
>
>On Thu, 20 Jun 2002, Benjamin Herrenschmidt wrote:
>>
>> Looking at how other kind of device trees are doing (typically
>> Open Firmware), I beleive this can be acheived by having a "type"
>> node (ie. file).
>
>I think you're right. Embedding types into naming makes for easy examples
>of using "find /devices -name ..." to look cool, but it also likely makes
>for rather cumbersome names, _and_ there are tons of devices that want to
>expose multiple different capabilitites ("it's not just a floor wax, it's
>a dessert topping too!").

Which is +/- dealt with in open firmware by also having a "compatible"
property that contain a list of names which this device is compatible with.

The "type" and "class" proper says if you are dealing with a bridge, a disk,
a serial port, etc... (but we could refine that into separate types/subtypes,
like a serial port beeing a type "char device" and subtype "serial port")

The compatible says which what kind of HW you are compatible with (it's
a list), which can be the name of other HW, but can also be generic types.
One example is NE2k compatible cards. They can have a specific name, a type
of "ethernet adapter" (or just ethernet to make things simple) a class
of "network device" and compatible "ne2k".

The "compatible" isn't exactly relative to the kind of service you provide,
this is the job of "device_type" and "class", at least in OF world, but
more the kind of HW you are compatible with (to help pick the proper
driver), though that don't necessarily make sense in driverfs. It's just
that the idea could be reused.

>> Also, there are lots of good reasons to put device/driver settings as
>> "properties" of the device node in the device tree, which ends up having
>> proc-like files under each device node.
>
>You're bound to have multiple files under each node anyway, for things
>like partition information etc. Yes.
>
>> We could define some standard ones (like the device type) and provide a
>> simple way (proc-like) for drivers to add more properties, thus replacing
>> in most cases the need for ioctls.
>
>Absolutely. The current driverfs thing does some of that (the "name"
>thing, mainly useful for havign uniform naming between different tools,
>and PCI devices for example all get a standard set of property files
>from the bus driver).
>
>But it should hopefully be driven by real need, not just "cool feature".
>Which is always a chicken-and-egg issue, of course.

Well, I have a bunch of real needs for it easily available ;) But in lots
of case, I beleive slowly replacing most ioctl's in drivers with that would
make sense. I _think_ Patrick and I agree on that, and It's something I want
to discuss at OLS/KS, probably as part of the Power Management BOF.

Ben.

Re: [PATCH] /proc/scsi/map

[Oliver Xymoron]

On Thu, 20 Jun 2002, Linus Torvalds wrote:

> On Thu, 20 Jun 2002, James Bottomley wrote:
> >
> > We should probably have some more discussion about the layout of the device
> > tree, particularly if it's going to be consistent with other devices like ide
> > discs and cds.
>
> Absolutely. I suspect that the _real_ issues start coming up only once
> people start using this for useful work, and we should just accept that
> the format (for now) is in flux. But that doesn't mean that we shouldn't
> try to make it reasonably sane from the very start.
>
> And make sure that the naming convention works for both IDE and SCSI (ie
> there should be a way to figure out _portably_ whether a device is a disk
> or CD-RW or whatever, without even knowing whether it's SCSI or IDE).

There are other device classes beyond disks we need to do similar things
with that we ought to figure out at the same time. Examples off the top of
my head: disk (disk? cdaudio? dvd? cdrw?), sound (wave table? 3d?), v4l
(tuner? radio? mpeg?), net (wireless?).

One possibility is an "interfaces" file that lists the types of interfaces
that a device supports, possibly along with major:minor for that
interface. Then you can do find /devices -name interfaces | xargs grep
disk to locate your disks..

Another general question is how to fit "virtual" devices that aren't
associated with a bus into this scheme. For instance, PPP, VPNs, loopback
block devices, ramdisks, iSCSI, NBD. While you might argue that most of
these aren't really devices, iSCSI is every bit as "real" as a "local" FC
disk. And then you get into logical devices ala LVM and RAID..

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> I personally think that the biggest problem with driverfs is it's lack of
> a 2.4.x counterpart. Although the filesystem itself should be fairly
> easy

Well, the thing just does not exist in 2.4.X. I can't see how this can
be helped. [It would be usefull. This way it is close to impossible to
make S3 work nicely in 2.4.X.]
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Andries Brouwer wrote:
>
> At present this does not look very useful, but it may have future.

Nobody is actually using it yet, so there hasn't been much feedback (and,
for the same reason, not much reason for driver writers to care -
everything that shows up there now ends up being pretty much built by the
bus that contains the devices rather than any device-specific information
itself).

> But there is a pressing present problem. What name do my devices have?
> I plug in a SmartMedia card reader. It will become some SCSI device.

That's a user-space issue, the kernel is not going to make any policy.
We've seen where policy takes us with devfs.

User space is notified of new devices through /sbin/hotplug (another thing
that USB and PCI do correctly, and SCSI doesn't do), which is really quite
orthogonal to driverfs. You can use one without the other, and in fact
today many people _do_ use /sbin/hotplug without actually using driverfs.

The /sbin/hotplug interface gives enough information that you can load
drivers (if the kernel couldn't figure it out on its own using existing
drivers), set up devices (network device routing, but possibly also
automated partitioning, or bus scanning).

But driverfs also gives information that /sbin/hotplug doesn't:

 - existing devices (ie for "events" that happened before boot, including
   obviously non-hotpluggable stuff)

 - relationships between them (ie the hierarchy)

 - relationships between devices and drivers (this is not made available
   yet, although the infrastructure is there: the idea is that you can see
   which driver handles a device, but also which devices a driver handles)

 - relationships between devices and things like the networking layer (ie
   the interface quite naturally extends to doing things like symlinks
   like "/devices/networking/eth0 -> /devices/root/pci0/00:1e.0/04:04.0"

In other words, it's just a way of exposing information that the kernel
already has, and that the kernel has to have _anyway_.

It also has the _potential_ to allow users to create their own
relationships. In particular, it should be rather easy to expose a symlink
to the "canonical name" in the kernel, and have a device manager that just
walks the devices in /devices, and updates them so that you get things
like

 - my SCSI controller:

	/devices/root/pci0/00:02.0/02:1f.0/03:07.0

 - bus 1 on that controller:

	[..]/02:1f.0/03:07.0/bus1/

 - id 2 on that controller:

	[..]/02:1f.0/03:07.0/bus1/id2

 - lun 0 on that controller

	[..]/02:1f.0/03:07.0/bus1/id2/lun0/

 - partition 1 on that disk

	[..]/03:07.0/bus1/id2/lun0/part1/

 - linkage to the "old name" world, with permissions:

	[..]/lun0/part1/traditional -> /dev/sdb1

(whether that "traditional name" linkage is done automatically by the
kernel using the canonical names, or by /sbin/hotplug together with a
bootup script, is an implementation detail. Because I would personally
prefer to avoid the naming flamewar, I'd prefer it to be in user space,
but I won't scream _too_ loudly if the kernel defaults at least the
standard names on its own.

These are all things that the kernel already knows about, they just
haven't had "struct device"s associated with them.

> Of course file system names are free, so instead of asking what sdX
> this device is, I should ask what major:minor this device is.

That is quite possible, and it all fits very well into the structure.

NOTE NOTE NOTE! Driverfs on _purpose_ does not handle permissions, and
has rather long names (you need long names if they are meaningful). That
means that it is _not_ a replacement for /dev itself. It's not meant to
be, and it really shouldn't be. Think of it as nothing but a virtual
filesystem that exposes _kernel_level_ relationships between devices.

Nothing more, nothing less.

But "what major/minor is this device on" is definitely such a kernel-level
relationship.

> In other words, there is the difficult naming problem,
> but there is also the translation problem. The user does
> not recognize the device as USB device 04e6:0005:...
> She thinks of this thing as her DaneElec card reader.

Note that the _user_ really shouldn't use driverfs directly.

If you reall ysee it as a way for the kernel to expose it's relationships,
you realize that it's useful for things like device managers, and for
whatever random system program that wants to find out about the hw layout.
Installers, and yes, things like CD recorder programs etc.

The user should generally only interact indirectly with it. Possibly
through a nice graphical user interface that uses the relationships to let
the user select a printer (instead of "lp0", you can show what printers
are in the system, what names they reported etc).

Is this something unique to driverfs? No. We _do_ have things like
/proc/scsi and /proc/ide etc, and they obviously work for most things. But
they are all ad-hoc, and they _cannot_ be anything else than ad-hoc
without some structure to glue them together.

driverfs _is_ that structure. And it isn't much else.

> That information is not easily obtainable without his patch.
> I do not see that driverfs provides such information.

But you caould come up with a diverfs-based patch that _also_ easily
obtains all the same information, and does it in a format that when the
same information is relevant in IDE disks, IT CAN LOOK THE SAME!

That's really the whole point. A clearinghouse for information.

		Linus
>

Re: [PATCH] /proc/scsi/map

[Martin Schwenke]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> But driverfs also gives information that /sbin/hotplug doesn't:

    Linus> [...]

    Linus> In other words, it's just a way of exposing information
    Linus> that the kernel already has, and that the kernel has to
    Linus> have _anyway_.

Does it have to be limited ot information that the kernel already has?

In particular, I'm thinking of the SCSI standard inquiry and EVPD
inquiry pages.  Mike Sullivan's patch does some SCSI inquiries and
extracts information from the results.  I'm wondering if the SCSI
driver could just do all of the available EVPD inquiries (available
pages are listed in the TOC on EVPD inquiry page 0), and use driverfs
to expose all of that (binary) information.

Right now the inquiries can be done from userspace using an ioctl().

peace & happiness,
martin

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Fri, 21 Jun 2002, Martin Schwenke wrote:
>
> Does it have to be limited ot information that the kernel already has?

No, but on the other hand I don't want the filesystem to be a bloat thing.

Right now all the filesystem code is basically just the regular dentry
tree (same as ramfs etc). And the data structures are largely data
structures that we have to carry around anyway. 

Bit if somehting is really _useful_ to export to user space through the fs
model and it makes things easier, that's probably good. Naming is
definitely one of those things - I generally like how the thing looks in a
file managers tree-view, but some of the names suck and that shows up cery 
clearly at that point, liiking in at 10.000'.

(Tha ACPI "shouting disease" is really sad. I remember my old VIC-20, and
how you used all-caps, but I don't think the ACPI people were sentimental.  
They apparently just _like_ ugly four-letter ALL-CAPS names).

		Linus

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> (Tha ACPI "shouting disease" is really sad. I remember my old VIC-20, and
> how you used all-caps, but I don't think the ACPI people were sentimental.  
> They apparently just _like_ ugly four-letter ALL-CAPS names).

"Keep ACPI shouting disease out of kernel!"

;-)

[Just went to canada and they give me some meaningless flyier on
mounth-and-foot disease.]

What if we just invert case on everything acpi related? But their
names will not look nice anyway. But what we could do is having
devices/acpi (not devices/ACPI).
									Pavel


-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[Ihno Krumreich]

On Thu, Jun 20, 2002 at 11:11:45AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 20 Jun 2002, Andries Brouwer wrote:
> >
> > At present this does not look very useful, but it may have future.
> 
> Nobody is actually using it yet, so there hasn't been much feedback (and,
> for the same reason, not much reason for driver writers to care -
> everything that shows up there now ends up being pretty much built by the
> bus that contains the devices rather than any device-specific information
> itself).
> 
> > But there is a pressing present problem. What name do my devices have?
> > I plug in a SmartMedia card reader. It will become some SCSI device.
> 
> That's a user-space issue, the kernel is not going to make any policy.
> We've seen where policy takes us with devfs.
> 


Hello,

by following the discussion I still miss a naming sceme for
devices like disks, tapes, cdrom for the user (no kernelhackers, but the
daily user running the system for some productive work). Does there exist
a naming sceme for persistant names for those devices? I think of something
like scsidev (http://www.garloff.de/kurt/linux/scsidev/#scsidev). 

I think the scsidev idea could be extended to a general sceme that
satisfies all technologies (not only ide and scsi).

I think of something like 

/dev/<device-type>/<technologie>_<Uniq-Number>_<Bus-number>_<Target>_<Lun>_<Device_type_specific>

<device-type> would be disks, tapes, cd-rom and other devices (scanner?)

<technologie> is something really readable for the user (ide, scsi, dasd (dasd are
              disks on the IBM zSeries)

<Uniq-number>	something to make a device uniq. examples for this could be:
                - PC the I/O-port used by the controller
		- DASD the device-port where the dasd is assigned
<bus-Number>
<Target>
<Lun>		As intented by SCSI. On technologies where they make no sense
		just leave them 0 (for example dasd don`t have that).

<device_type_specific>	depends on the device type. 
			for disks this is the partition-number
			for tapes rewind, norewind, compression, density

examples:

disks:

/dev/disks/ide_01f0_0_0_0_0	for the whole IDE disk
/dev/disks/ide_01f0_0_0_0_1	for partition 1
.
.
/dev/disks/ide_01f0_0_0_0_31	for partition 31

/dev/disks/scsi_0330_0_1_0_0	for the controller at port 0x330, disk bus 0 target 1, lun 0
/dev/disks/scsi_0330_0_1_0_1	for partition 1
.
.
/dev/disks/scsi_0330_0_1_0_15	for partition 15

/dev/disks/dasd_0150_0_0_0_0	for dasd at device-port 0x150, whole disk
/dev/disks/dasd_0150_0_0_0_1	for partition 1
.
.
/dev/disks/dasd_0150_0_0_0_3	for partition 3

tapes:

/dev/tapes/scsi_0330_0_2_0_r	auto-rewind SCSI-Tape at controller at Port 0x330
/dev/tapes/scsi_0330_0_2_0_n	no-rewind SCSI-Tape at controller at Port 0x330


Beside some standard devices, the devices could be created

- at system start for coldplugged devices
- by /sbin/hotplug for hotpluged devices

This naming sceme could be used for kernel 2.4 by creating nodes and for
kernel 2.5 by making symbolic links to /devices.

something forgotten?


Ihno

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> by following the discussion I still miss a naming sceme for
> devices like disks, tapes, cdrom for the user (no kernelhackers, but the
> daily user running the system for some productive work). Does there exist
> a naming sceme for persistant names for those devices? I think of something
> like scsidev (http://www.garloff.de/kurt/linux/scsidev/#scsidev). 
> 
> I think the scsidev idea could be extended to a general sceme that
> satisfies all technologies (not only ide and scsi).
> 
> I think of something like 
> 
> /dev/<device-type>/<technologie>_<Uniq-Number>_<Bus-number>_<Target>_<Lun>_<Device_type_specific>
...
> Beside some standard devices, the devices could be created
> 
> - at system start for coldplugged devices
> - by /sbin/hotplug for hotpluged devices
> 
> This naming sceme could be used for kernel 2.4 by creating nodes and for
> kernel 2.5 by making symbolic links to /devices.

We're intending to leave the naming scheme entirely up to userspace. The 
kernel will not create/impose any type of default naming scheme for 
devices. 

When a device is registered with the class that it belongs to (disk, 
cdrom, sound, etc), /sbin/hotplug will be called with the path to the 
device. This path will correspond to a driverfs path for the device. 
/sbin/hotplug will then be able to ascertain all necessary information 
about the device to create device nodes for it, including major and minor 
numbers. 

It will be up to userspace to process this data to determine what device 
nodes it will create. We have some starting ideas concerning this. Once I 
get settled back in, I'll post some documentation on everything that was 
discussed in Ottawa, and how we propose to do this...

	-pat

Re: [PATCH] /proc/scsi/map

[Greg KH]

On Thu, Jun 20, 2002 at 06:55:53PM +0200, Andries Brouwer wrote:
> USB device 0000:0000
> figure out some name...

<snip>

Heh, this is the first time anyone has ever reported those names to me.
Yes, the names aren't very useful yet, but give us time, patches gladly
accepted to fix this :)

The physical representation of the USB trees within the PCI tree is
(imho) a _vast_ improvement over anything we have had before, and that
is currently working quite well.

Now to hook up the USB bus code to the struct bus_type style code, like
PCI now is...

thanks,

greg k-h

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

[ Sorry for the lack of noise in the last week; I was unable to read email 
for the last week, and am only starting to catch up. ]

> Try it out yourself. Just do
> 
> 	mount -t driverfs /devices /devices
> 
> and then look at the whole glory in some graphical file manager to get a
> view of the tree (actually, most file managers are somewhat confused about
> the fact that the directory counts don't reflect sub-directories, so you
> may have to open the subdirectories by hand, whatever. That's a bug.
> Should be fixed. I'm cc'ing Pat)

ACK. I'm looking into it; should have something before I leave for Ottawa. 

> End result: Linux has a notion of a "struct device", and it's an internal
> kernel representation of the whole bus structure as far as Linux can tell.
> It's then exported as a filesystem, but that's not the important part: the
> device tree is valid (and important) even when it's not exported to user
> space, simply because things like power-management events etc have to
> honor the tree and traverse it in the right order.

This is an important point, and one I will be stressing heavily in Ottawa. 
The device model != driverfs. The new device model is about refining the 
kernel representation of device-related objects: devices, drivers, bus 
drivers, and class drivers. 

A filesystem just happens to map very nicely onto internal hierarchial 
structures, which is why it was created. driverfs makes no sense with the 
device model infrastructure to populate it. But, the device model core can 
theoretically be separated from the driverfs implementation. 

> If you like OF, you can actually use OF to _populate_ the Linux device
> tree. The people who like ACPI (yet, they exist) do that with ACPI. The
> Linux device tree is _completely_ agnostic, and absolutely does _not_ want
> to know or depend on firmware issues, since firmware is not portable.
> 
> (Right now ACPI does this, so all the strange ACPI nodes will show up in
> /devices/root/ACPI if you have ACPI enabled).

I made a patch a while back that mapped ACPI-enumerated devices back to 
physical objects in the system. This got rid of the duplicate ACPI 
entries, and should be done generically enough to port it to other 
firmware enumerators. (It depends a couple of other patches that have not 
made it out yet, but I'll bring the whole slew to Canada so people can 
see how it works).

OF wrt the device tree is something I've talked to a few people about. 
Things were much more nebulous than now, and talk is still cheap. Ideally, 
OF should populate the device tree in a similar manner, but I don't think 
anyone has had the time to make it happen...

	-pat

Re: [PATCH] /proc/scsi/map

[Mike Touloumtzis]

On Thu, Jun 20, 2002 at 08:13:22AM -0700, Linus Torvalds wrote:
>
> Try it out yourself. Just do
> 
> 	mount -t driverfs /devices /devices

Doesn't "/drv" mesh better with the traditional Unix naming aesthetic?

:-)

miket

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]

Hi Linus,

On Wed, Jun 19, 2002 at 10:03:16PM -0700, Linus Torvalds wrote:
> On Thu, 20 Jun 2002, Kurt Garloff wrote:
> > 
> > find attached a patch (against 2.5.23-dj2) to the SCSI subsystem which 
> > adds a file /proc/scsi/map, which provides a listing of SCSI devices,
> > enumerated by the CBTU/HCIL tuple and the high-level devices attached to
> > them. 
> 
> I really despise this.

Thanks for your feedback.

Actually, I think you want to address a different problem than I want to.

I do believe that the scsi subsystem does not expose enough information for
many things. 

Look at /proc/scsi/scsi: The information is useful for the reader who wants
to know what devices he has and were found by the SCSI subsystem.

And completely useless for any program that wants to find a scanner,
CD-Writer, ... as there is no connection to the high-level drivers attached
to them. Which means that all these programs basically contain their own
SCSI scanning code, which means opnening all sg devices and collecting the
information. I do not think that this is a good idea that a lot of userspace
programs need to do a lot of effort to get some information that could just
be exported by the kernel.

But I indeed had persistent naming in mind as well and mentioned it, so this
is probably why the discussion went that way.
scsidev, which I took over from Eric Youngdale some time ago, tries to
provide persistent naming for SCSI devices and suffers the problem, that
it can't work reliably, as open() of sr/st/osst devices can fail because
devices are already in use (-EBUSY) or have no medium inserted. (O_NONBLOCK
does not always help.) And it can take considerable time or cause unwanted
side-effects. 

You're right that just enumerating all scsi devices in a somewhat more
persistent way does not constitute a complete solution to the problem of
persistent naming of attached storage devices. That is something that would
need to be addressed at a higher level and not inside SCSI midlevel, of
course.

But I still think the SCSI subsystem should report which SCSI (low-level)
device is mapped to what high-level driver.
Would you accept a patch that adds a line like

Host: scsi3 Channel: 00 Id: 12 Lun: 00
  Vendor: IBM      Model: DPSS-336950N     Rev: S84D
  Type:   Direct-Access                    ANSI SCSI revision: 03
  Attached drivers: sg12(c:15:0c) sdf(b:08:50)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to /proc/scsi/scsi ?

Actually that was my first idea, but I was reluctant to change the format of
an existing file, as it might be parsed by existing code. 
But, given the uselessness of /proc/scsi/scsi for code, I guess that's
a small risk ... 

> It's just _wrong_ to have one file with a collection of devices in it, and 
> it is _doubly_ wrong when that one file
> 
>  - is limited to a (arbitrary) subset of the disks in your system

You mean all disks driven by the SCSI subsystem, right?

>  - has completely bogus information about "location" that has nothing to 
>    do with real life, yet pruports to be an "address" even though it 
>    obviously isn't.

The CBTU tuple uniquely addresses a SCSI device in a running system.
It's just not persistent against configuration changes, unfortunately.
But it's reported by /proc/scsi/scsi as well and therefore useful to
find back in map, IMHO.

[...]
> Either you enumerate things without any structure (like the current SCSI
> layer does: disk0, disk1, disk2 ...) or you give full their addresses.  
> Don't do the half-assed thing.

I would certainly like to see code at block layer that does provide the
infrastructure to see persistent names for all sort of attached devices,
especially disks.

> PLEASE don't add these kinds of SCSI-specific hacks, that are _useless_ to
> find other types of disks, and that makes no sense, and will not work for
> things like DAC960, for IDE, or for anything else that just ignores the 
> SCSI layer (even if it physically uses SCSI disks, like the DAC960 setup).

Please consider the possibility of adding the reporting of the attached
high-level drivers to /proc/scsi/scsi

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Kurt Garloff wrote:
> >
> > I really despise this.
>
> Thanks for your feedback.

You're too polite for your own good ;)

> Actually, I think you want to address a different problem than I want to.
>
> I do believe that the scsi subsystem does not expose enough information for
> many things.
>
> Look at /proc/scsi/scsi: The information is useful for the reader who wants
> to know what devices he has and were found by the SCSI subsystem.

I would rephrase that as "the information is only useful to find devices
found by the SCSI midlayer".

And my point is that you don't make it any better. Your patch perpetuates
this lopsided world-view that people should care. THAT is the fundamental
part that I don't like, because it drags us down for the future.

And in the end, if that is the case, it doesn't _help_ if it is "useful"
or not from a maintenance standpoint. From a maintenance standpoint, a
SCSI-only interface is a total horror.

I will bet you that there are more IDE CD-RW's out there than there are
SCSI devices. The fact that people use ide-scsi to write to them is a
hopefully very temporary situation, and the command interface is going
to move to a higher layer.

At which point your SCSI-centric world-view now became a total failure, as
it no longer shows up most of the devices that can write CD's or DVD's any
more.

Sure, it will still continue to show "what devices were found by the SCSI
midlayer". But user applications will have to scan other stuff, and find
the IDE-specific stuff, and then whatever else is out there.

See the problem?

If, on the other hand, you try to take the bull by the horns and realize
that the notion of "searching for devices" has nothing to do with SCSI at
_all_, you may find yourself with more work on your hands, but on the
other hand, wouldn't it be just so _nice_ to be able to do

	find /devices -name cd-rw

to find all cd-rw's in the system? Does it work that way now? Absolutely
not. But most of the infrastructure is actually there today. Wouldn't it
be _nice_ if after the CD-writing app has found all cd-rw's, it just opens
them, and the kernel will automatically open the right device (whether it
is a scsi-generic one or a IDE one)?

(No, I'm not serious about the "cd-rw" name itself, I'm just making a
simple example).

> And completely useless for any program that wants to find a scanner,
> CD-Writer, ... as there is no connection to the high-level drivers attached
> to them.

I'm not disputing that.

However, I _am_ disputing that this should be done in some SCSI-centric
way that works for SCSI but nothing else.

When I want to find a CD-ROM, I don't want to worry about whether it is
IDE or SCSI. I would

> But I still think the SCSI subsystem should report which SCSI (low-level)
> device is mapped to what high-level driver.
> Would you accept a patch that adds a line like
>
> Host: scsi3 Channel: 00 Id: 12 Lun: 00
>   Vendor: IBM      Model: DPSS-336950N     Rev: S84D
>   Type:   Direct-Access                    ANSI SCSI revision: 03
>   Attached drivers: sg12(c:15:0c) sdf(b:08:50)
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to /proc/scsi/scsi ?

That would be less offensive to me if only because it doesn't introduce a
_new_ interface that is SCSI-only, it only extends on an old one. It makes
no _technical_ difference, but I'd rather extend an old broken interface
than introduce a totally new broken interface.

> >  - is limited to a (arbitrary) subset of the disks in your system
>
> You mean all disks driven by the SCSI subsystem, right?

Yes. In particular, you miss the great majority of disks that way (IDE),
and you even miss SCSI disks that are behind controllers where the driver
writer refused to use the mid-layer.

For CD burning, you may be of the opinion that everything - including IDE
- _has_ to be SCSI layer anyway (because that is how it is right now), but
that is not going to be the case all that much longer, I hope.

> >  - has completely bogus information about "location" that has nothing to
> >    do with real life, yet pruports to be an "address" even though it
> >    obviously isn't.
>
> The CBTU tuple uniquely addresses a SCSI device in a running system.

Yes, but that's not enough. Other people are still asking for physical
location, so let's try to fix two things with _one_ generic interface that
is at least agnostic to how a device is connected to the kernel..

		Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> Yes, but that's not enough. Other people are still asking for physical
> location, so let's try to fix two things with _one_ generic interface that
> is at least agnostic to how a device is connected to the kernel..


First and foremost please allow me to state that I support
entierly the view of Linus that we should try to be as much
as possible device type agnostic for generic functionality
like detection of partitions on block devices. Thats all what
operating systems are about: abstraction of hardware interfaces.
But:

1. There was the mistake of using different major numbers
for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).

2. Then came devfs along and promised to slove this problem.
    But people still complained about not beeing ablve to boot, after
    I changed the registration name for IDE devices from "ide" to "ata".
    This showed nicely that devfs doesn't cut it. It's useless for
    the purpose of unification of access methods apparently.

3. Now comes driverfs, which is basically a Solaris driver tree clone and
    *repeats* the same errors as 1. and 2.:


  ./
./bus
./bus/usb
./bus/usb/drivers
./bus/usb/devices
./bus/usb/devices/002001
...
./bus/usb/devices/001000
./bus/pci
./bus/pci/drivers
./bus/pci/drivers/parport_pc
..
./bus/pci/drivers/usb-uhci-hcd
./bus/pci/drivers/e100
./bus/pci/devices
./bus/pci/devices/00:0c.1
...
./bus/pci/devices/00:00.0

1. The /drivers information is useless. modutils are maintining they
own information. For some jet unknow reason they manage to
maintain te hierarchy entierly in user space.

The bus suffix. is useless for any purpose I can imagine.
Which kind of view is the above supposed to present?

./root

2. What is this root prefix good for?!
./root/pci0

3. Solaris is separating the name and enumeration part by @ for
good reaons.

./root/pci0/00:0c.1
./root/pci0/00:0c.1/resources

4. resources? What is the semantics of this supposed to be?
IO ranges, memmory mappings? Whatever. This is jet another
ASCI view for data which is too specific and should be only
maintained by the drivers itself internaly as it is.
Since it's not used now it will open jet another room
for arbitrary formating and random useless entires problems in the future.
Much like the mess in /proc only repeated for every single device on the
system.

./root/pci0/00:0c.1/irq

5. This is showing that the resources file above is useless, becouse
I would rather love to consider irq as a resource.

./root/pci0/00:0c.1/power
./root/pci0/00:0c.1/name

6. The /name is entierly redundant logically to the fact that we
have already a unique path to the device. For "pretty" printing
we have userspace. For PCI it's for example repeating the
ID info found already by lspci.

./root/pci0/00:07.2/usb_bus

7. What is the _bus? suffix good for? How does this releate
to the /bus hierarchy?

./root/pci0/00:07.2/usb_bus/00

9. Contrary to PCI we enumerate the busses apparently
by one dir level and not a suffix on the usb prefix.

./root/pci0/00:07.1/ata@00
./root/pci0/00:07.1/ata@00/sd@0,0
./root/pci0/00:07.1/ata@00/sd@0,0/power
./root/pci0/00:07.1/ata@00/sd@0,0/name
./root/pci0/00:07.1/ata@00/power
./root/pci0/00:07.1/ata@00/name

Here I'm trying to fit the whole in some kind of
physical view. I did sneak in the sd instead of
hd in the futile hope that SCSI will pick up the same
name. And I buy in to the idea of separating
the enumeratin for the naming by a @.
This way one has only to enumerate the
dir only and no room for possible ambiguity is present.
But it was entierly behind me how to fit this
in to the sheme other sd@4,0:h,raw
OS-es are using. And finally how would one fit this in to the
partitioning shemes? For the system aprtitions are simply
block devices hanging off the corresponding block device.

However we can see that the driver filesystem is
inconsistant on the kind of enumeration it should
provide. See the colon in sd@0,0 and the whole subdir
crazyness... So do we distingish different devices by a subdir?
Or do we do it by an unique enumeration suffix?

And last but not least: I still don't see any kind
of abstraction there which would allow to easly enumerate
for example all disks in the system.

However a simple major number range for disks 1 to 16000 would
be ideal. And I bet that at some (not too distant) day we will
simple have to reassign those numbers and be done.

Really people please let you inspire:

./pci@1f,4000/scsi@3/sd@9,0:f
./pci@1f,4000/scsi@3/sd@9,0:h,raw
./pci@1f,4000/scsi@3/sd@a,0:a
./pci@1f,4000/scsi@3/sd@a,0:b
./pci@1f,4000/scsi@3/sd@a,0:c
./pci@1f,4000/scsi@3/sd@a,0:a,raw
./pci@1f,4000/scsi@3/sd@a,0:b,raw

And just lets avoid the mistakes in the above.
I love the ,raw part for example instead of some
root mapping to completely different major numbers.



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

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> Yes, but that's not enough. Other people are still asking for physical
> location, so let's try to fix two things with _one_ generic interface that
> is at least agnostic to how a device is connected to the kernel..


First and foremost please allow me to state that I support
entierly the view of Linus that we should try to be as much
as possible device type agnostic for generic functionality
like detection of partitions on block devices. Thats all what
operating systems are about: abstraction of hardware interfaces.
But:

1. There was the mistake of using different major numbers
for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).

2. Then came devfs along and promised to slove this problem.
    But people still complained about not beeing ablve to boot, after
    I changed the registration name for IDE devices from "ide" to "ata".
    This showed nicely that devfs doesn't cut it. It's useless for
    the purpose of unification of access methods apparently.

3. Now comes driverfs, which is basically a Solaris driver tree clone and
    *repeats* the same errors as 1. and 2.:


  ./
./bus
./bus/usb
./bus/usb/drivers
./bus/usb/devices
./bus/usb/devices/002001
...
./bus/usb/devices/001000
./bus/pci
./bus/pci/drivers
./bus/pci/drivers/parport_pc
..
./bus/pci/drivers/usb-uhci-hcd
./bus/pci/drivers/e100
./bus/pci/devices
./bus/pci/devices/00:0c.1
...
./bus/pci/devices/00:00.0

1. The /drivers information is useless. modutils are maintining they
own information. For some jet unknow reason they manage to
maintain te hierarchy entierly in user space.

The bus suffix. is useless for any purpose I can imagine.
Which kind of view is the above supposed to present?

./root

2. What is this root prefix good for?!
./root/pci0

3. Solaris is separating the name and enumeration part by @ for
good reaons.

./root/pci0/00:0c.1
./root/pci0/00:0c.1/resources

4. resources? What is the semantics of this supposed to be?
IO ranges, memmory mappings? Whatever. This is jet another
ASCI view for data which is too specific and should be only
maintained by the drivers itself internaly as it is.
Since it's not used now it will open jet another room
for arbitrary formating and random useless entires problems in the future.
Much like the mess in /proc only repeated for every single device on the
system.

./root/pci0/00:0c.1/irq

5. This is showing that the resources file above is useless, becouse
I would rather love to consider irq as a resource.

./root/pci0/00:0c.1/power
./root/pci0/00:0c.1/name

6. The /name is entierly redundant logically to the fact that we
have already a unique path to the device. For "pretty" printing
we have userspace. For PCI it's for example repeating the
ID info found already by lspci.

./root/pci0/00:07.2/usb_bus

7. What is the _bus? suffix good for? How does this releate
to the /bus hierarchy?

./root/pci0/00:07.2/usb_bus/00

9. Contrary to PCI we enumerate the busses apparently
by one dir level and not a suffix on the usb prefix.

./root/pci0/00:07.1/ata@00
./root/pci0/00:07.1/ata@00/sd@0,0
./root/pci0/00:07.1/ata@00/sd@0,0/power
./root/pci0/00:07.1/ata@00/sd@0,0/name
./root/pci0/00:07.1/ata@00/power
./root/pci0/00:07.1/ata@00/name

Here I'm trying to fit the whole in some kind of
physical view. I did sneak in the sd instead of
hd in the futile hope that SCSI will pick up the same
name. And I buy in to the idea of separating
the enumeratin for the naming by a @.
This way one has only to enumerate the
dir only and no room for possible ambiguity is present.
But it was entierly behind me how to fit this
in to the sheme other sd@4,0:h,raw
OS-es are using. And finally how would one fit this in to the
partitioning shemes? For the system aprtitions are simply
block devices hanging off the corresponding block device.

However we can see that the driver filesystem is
inconsistant on the kind of enumeration it should
provide. See the colon in sd@0,0 and the whole subdir
crazyness... So do we distingish different devices by a subdir?
Or do we do it by an unique enumeration suffix?

And last but not least: I still don't see any kind
of abstraction there which would allow to easly enumerate
for example all disks in the system.

However a simple major number range for disks 1 to 16000 would
be ideal. And I bet that at some (not too distant) day we will
simple have to reassign those numbers and be done.

Really people please let you inspire:

./pci@1f,4000/scsi@3/sd@9,0:f
./pci@1f,4000/scsi@3/sd@9,0:h,raw
./pci@1f,4000/scsi@3/sd@a,0:a
./pci@1f,4000/scsi@3/sd@a,0:b
./pci@1f,4000/scsi@3/sd@a,0:c
./pci@1f,4000/scsi@3/sd@a,0:a,raw
./pci@1f,4000/scsi@3/sd@a,0:b,raw

And just lets avoid the mistakes in the above.
I love the ,raw part for example instead of some
root mapping to completely different major numbers.

Re: [PATCH] /proc/scsi/map

[James Bottomley]

dalecki@evision-ventures.com said:
> 1. There was the mistake of using different major numbers for SCSI and
> IDE/ATAPI devices. (disk and CD-ROM are the most striking). 

Don't confuse major numbers (which are really a kernel internal thing) with 
names.  Major numbers serve a very useful purpose in allowing quick device 
driver identification.  It would be an unhappy state of affairs if we had to 
parse both the major and minor numbers extensively just to identify the device 
driver to handle the request.  There's no reason why we can't use a consistent 
naming scheme for all CD-ROMs and yet have them using different major numbers.

One of the advantages of driverfs, I think, is that it separates the device 
name from a static entry in /dev which is tied to a major/minor number.

> 6. The /name is entierly redundant logically to the fact that we have
> already a unique path to the device. For "pretty" printing we have
> userspace. For PCI it's for example repeating the ID info found
> already by lspci. 

The /name is useful in the enterprise for persistent device identification.  
Leaves in the device tree can move as boxes are regconfigured.  The name entry 
helps you find your leaf again when this happens.  It also helps you find the 
same storage in a cluster regardless of the device driver or storage 
connection method.

> And last but not least: I still don't see any kind of abstraction
> there which would allow to easly enumerate for example all disks in
> the system. 

Doesn't this depend on the semantics provided in the device node (leaf)?  If 
you had a way of identifying disk devices (say from an empty type=disk file) 
then you could do a simple find to list all the disks in the system regardless 
of being SCSI, IDE, SSA etc.

James

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, James Bottomley wrote:
>
> > And last but not least: I still don't see any kind of abstraction
> > there which would allow to easly enumerate for example all disks in
> > the system.
>
> Doesn't this depend on the semantics provided in the device node (leaf)?  If
> you had a way of identifying disk devices (say from an empty type=disk file)
> then you could do a simple find to list all the disks in the system regardless
> of being SCSI, IDE, SSA etc.

Right now, the _biggest_ problem with driverfs is that it only does the
infrastructure, and precious little of the "real work".

For example, to be useful, every driver that knows about disks should make
sure they show up with some standard name (the old "disk" vs "disc" war
;), exactly so that you _should_ be able to do something like

	find /devices -name disk*

and be able to enumerate every disk in the whole system.

Of course, this is also the kind of meta-information that driverfs can
give "for free", ie since the kernel basically knows it is a disk, the
kernel can also directly expose the relationship of "these are all the
disks I know about". Ie again

	"kernel device relationship" == "driverfs"

which means that it should be fairly trivial to just do

	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
	               disk1 -> ../../pci0/00:02.3/usb_bus/001000/dev1

the same way that Pat already planned to do the mappings for network
devices in /devices/network/eth*.

Is this done? No. But is it fundamentally hard? Nope. Useful? You be the
judge.  Imagine yourself as a installer searching for disks. Or imagine
yourself as a initrd program that runs at boot, setting up irq routings
etc before the "real boot".

			Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> For example, to be useful, every driver that knows about disks should make
> sure they show up with some standard name (the old "disk" vs "disc" war
> ;), exactly so that you _should_ be able to do something like
> 
> 	find /devices -name disk*

Not good. find /devices -name "/sd@* -- will be unambigious.
There are good reaons they do it like they do on the "other unix OS"...

> and be able to enumerate every disk in the whole system.

> 
> 	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
                  ^^^^^^^^^^ You notice the redundancy in naming here :-).

> 	               disk1 -> ../../pci0/00:02.3/usb_bus/001000/dev1
> 
> the same way that Pat already planned to do the mappings for network
> devices in /devices/network/eth*.

Boah the chierachies are already deep enough. /devices/net/eth@XX
will cut it.

> Is this done? No. But is it fundamentally hard? Nope. Useful? You be the
> judge.  Imagine yourself as a installer searching for disks. Or imagine
> yourself as a initrd program that runs at boot, setting up irq routings
> etc before the "real boot".

Yes but again the most content files found there are already inventing
interfaces on the heap. /name /irq /resources /power this will end the same
as similar attempts ended already - in a mess.

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

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:

> For example, to be useful, every driver that knows about disks should make
> sure they show up with some standard name (the old "disk" vs "disc" war
> ;), exactly so that you _should_ be able to do something like
> 
> 	find /devices -name disk*

Not good. find /devices -name "/sd@* -- will be unambigious.
There are good reaons they do it like they do on the "other unix OS"...

> and be able to enumerate every disk in the whole system.

> 
> 	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
                  ^^^^^^^^^^ You notice the redundancy in naming here :-).

> 	               disk1 -> ../../pci0/00:02.3/usb_bus/001000/dev1
> 
> the same way that Pat already planned to do the mappings for network
> devices in /devices/network/eth*.

Boah the chierachies are already deep enough. /devices/net/eth@XX
will cut it.

> Is this done? No. But is it fundamentally hard? Nope. Useful? You be the
> judge.  Imagine yourself as a installer searching for disks. Or imagine
> yourself as a initrd program that runs at boot, setting up irq routings
> etc before the "real boot".

Yes but again the most content files found there are already inventing
interfaces on the heap. /name /irq /resources /power this will end the same
as similar attempts ended already - in a mess.

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Martin Dalecki wrote:
> >
> > 	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
>                   ^^^^^^^^^^ You notice the redundancy in naming here :-).

I'd rather have redundancy than have horrible names like just "0", thank
you very much.

It takes up no space, all the dentries are virtual anyway, and a dentry
embeds the storage for the first n characters (n ~16 or something like
that).

> Boah the chierachies are already deep enough. /devices/net/eth@XX
> will cut it.

There is _no_ excuse for being terse.

Also, never EVER use special characters like "@" unless there is _reason_
to use them. I don't see any reason to make a filesystem look like perl.

Please use sane names like "disknnn" over insane cryptographically secure
filesystem contents like "sd@nnn".

		Linus

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:
> 
> On Thu, 20 Jun 2002, Martin Dalecki wrote:
> 
>>>	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
>>
>>                  ^^^^^^^^^^ You notice the redundancy in naming here :-).
> 
> 
> I'd rather have redundancy than have horrible names like just "0", thank
> you very much.
> 
> It takes up no space, all the dentries are virtual anyway, and a dentry
> embeds the storage for the first n characters (n ~16 or something like
> that).
> 
> 
>>Boah the chierachies are already deep enough. /devices/net/eth@XX
>>will cut it.
> 
> 
> There is _no_ excuse for being terse.

Yes indeed:

ls 	DIR
cp 	COPY
mv      REANME
cat     TYPE

Note: the VMS stuff was even longer. You ever used the "shell" there?

> Also, never EVER use special characters like "@" unless there is _reason_
> to use them. I don't see any reason to make a filesystem look like perl.

The reaons is that it is making the splitup betwen the enumeration
and naming part very easy. Not just for scripts but for C code as well.
Numbers get user quite frequently for versioning as well.
And I tought the above should be mainly used by programs?

> Please use sane names like "disknnn" over insane cryptographically secure
> filesystem contents like "sd@nnn".

I'm so used to sd@ :-). Don't invent where you can borrow - or you will
go the esperanto way.

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

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Linus Torvalds napisał:
> 
> On Thu, 20 Jun 2002, Martin Dalecki wrote:
> 
>>>	/devices/disks/disk0 -> ../../pci0/00:02.0/02:1f.0/03:07.0/disk0
>>
>>                  ^^^^^^^^^^ You notice the redundancy in naming here :-).
> 
> 
> I'd rather have redundancy than have horrible names like just "0", thank
> you very much.
> 
> It takes up no space, all the dentries are virtual anyway, and a dentry
> embeds the storage for the first n characters (n ~16 or something like
> that).
> 
> 
>>Boah the chierachies are already deep enough. /devices/net/eth@XX
>>will cut it.
> 
> 
> There is _no_ excuse for being terse.

Yes indeed:

ls 	DIR
cp 	COPY
mv      REANME
cat     TYPE

Note: the VMS stuff was even longer. You ever used the "shell" there?

> Also, never EVER use special characters like "@" unless there is _reason_
> to use them. I don't see any reason to make a filesystem look like perl.

The reaons is that it is making the splitup betwen the enumeration
and naming part very easy. Not just for scripts but for C code as well.
Numbers get user quite frequently for versioning as well.
And I tought the above should be mainly used by programs?

> Please use sane names like "disknnn" over insane cryptographically secure
> filesystem contents like "sd@nnn".

I'm so used to sd@ :-). Don't invent where you can borrow - or you will
go the esperanto way.

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> But:
> 
> 1. There was the mistake of using different major numbers
> for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).
> 
> 2. Then came devfs along and promised to slove this problem.
>     But people still complained about not beeing ablve to boot, after
>     I changed the registration name for IDE devices from "ide" to "ata".
>     This showed nicely that devfs doesn't cut it. It's useless for
>     the purpose of unification of access methods apparently.
> 
> 3. Now comes driverfs, which is basically a Solaris driver tree clone and
>     *repeats* the same errors as 1. and 2.:

driverfs is not a Solaris driver tree clone. Sure, it's similar, but I 
assure no inspiaration was derived from Solaris. The same is true for the 
Windows Driver Model (though bits of inspiration may have filtered into 
the initial driver tree from WDM via the ACPI people).

driverfs does not care about major and minor numbers (yet). 

driverfs does not attempt to replace the /dev hierarchy.

That said, driverfs will use major/minor numbers in the future, but it
will not care about what they are or who owns them. It will also offer a
solution to the device naming problem (like devfs), and provide a 
mechanism for maintaining /dev compatability. But, I'm foreshadowing. 

>   ./
> ./bus
> ./bus/usb
> ./bus/usb/drivers
> ./bus/usb/devices
> ./bus/usb/devices/002001
> ...
> ./bus/usb/devices/001000
> ./bus/pci
> ./bus/pci/drivers
> ./bus/pci/drivers/parport_pc
> ..
> ./bus/pci/drivers/usb-uhci-hcd
> ./bus/pci/drivers/e100
> ./bus/pci/devices
> ./bus/pci/devices/00:0c.1
> ...
> ./bus/pci/devices/00:00.0
> 
> 1. The /drivers information is useless. modutils are maintining they
> own information. For some jet unknow reason they manage to
> maintain te hierarchy entierly in user space.

You mean e.g. ./bus/pci/drivers/ ? I don't think it's useless at all. It 
provides a mechanism for drivers to export attributes specific to the 
drivers themselves (and not specific to a particular device). For example, 
if you want to turn on debugging on the fly in the e100 driver, it could 
export a 'debug' file, which the user could toggle. It would turn on 
debugging for the entire driver on the fly. 

It likely has a module parameter to do the same thing. But, that parameter 
is not available if you statically compile it into the kernel. And, module 
parameters are not tweakable on the fly. 

Rusty and I are talking at the kernel workshop on Monday about parameters.  
One of the topics is where module parameters leave off and driverfs starts
up. It would be really really nice to unify the representation of these
types of parameters. 

Plus, something that is easy to do is create symlinks in the drivers' 
directory to the devices in the physical hierarchy for the devices it's 
driving. 

> The bus suffix. is useless for any purpose I can imagine.
> Which kind of view is the above supposed to present?

It's the 'bus' view. Each bus should have a struct bus_type object that it 
registers on startup. (See the documentation I sent out a couple of weeks 
ago). It's then inserted into a flat list of bus types. 

Each bus keeps a list of devices and drivers. These lists are moved to the 
struct bus_type for centralized management. 

Everything is exported via driverfs because it's easy to do so, and 
because it can potentially be very useful. 

> ./root
> 
> 2. What is this root prefix good for?!

Every system has the concept of a 'root' device. It's a virtual device 
that doresn't physically exist. It's the start of the device tree. 

> ./root/pci0
>
> 3. Solaris is separating the name and enumeration part by @ for
> good reaons.

'pci0' is the bus ID of the first PCI bridge. Devices that exist on the 
board itself and not on a peripheral bus don't have a standard for bus 
IDs. So, I went with <canonical name><instance number>. I thought it was 
pretty clear what it meant...

> ./root/pci0/00:0c.1
> ./root/pci0/00:0c.1/resources
> 
> 4. resources? What is the semantics of this supposed to be?
> IO ranges, memmory mappings? Whatever. This is jet another
> ASCI view for data which is too specific and should be only
> maintained by the drivers itself internaly as it is.
> Since it's not used now it will open jet another room
> for arbitrary formating and random useless entires problems in the future.
> Much like the mess in /proc only repeated for every single device on the
> system.

I think just the opposite is true. The resources file is added by the PCI 
layer and exports the BARs of the device. Every PCI device has this data. 
The formatting of this file is handled by the PCI layer. Yes, it may be 
specific to PCI devices, but it is standard for each PCI device. 

If we ever move the resources array to struct device, we can move the 
creation and the formatting of the resources file to the core. Then, it's 
standard for every device. 

I don't want driverfs to end up like procfs with the random formatting
problem. I want driverfs files to be ASCII-only files with one value per
file. This cannot be programmatically enforced, so we must rely on social
engineering to enforce it. 

[ Also, the resources file also violates the second rule, since it's an 
array of information, but I don't know any better way to represent this. ]

driverfs files are named attribute pairs, where the name of the attribute 
is the name of the file, and the value is the contents. I've talked with 
people before about making them even easier to create, read, and write, in 
ways that enforce one value of a specific type to be exported. (I.e. 
making them very restrictive). Someday...

> ./root/pci0/00:0c.1/irq
> 
> 5. This is showing that the resources file above is useless, becouse
> I would rather love to consider irq as a resource.

Sure, but it's a separate field. 

> ./root/pci0/00:0c.1/power
> ./root/pci0/00:0c.1/name
> 
> 6. The /name is entierly redundant logically to the fact that we
> have already a unique path to the device. For "pretty" printing
> we have userspace. For PCI it's for example repeating the
> ID info found already by lspci.

Sure. But, we already have the information in struct device. Instead of 
using lspci, lsusb, lsfoo to ascertain the name, you can just cat the name 
file for any device on the system. (Though, I basically agree with the 
premise that that information doesn't need to be in the kernel in the 
first place)

> ./root/pci0/00:07.2/usb_bus
> 
> 7. What is the _bus? suffix good for? How does this releate
> to the /bus hierarchy?

It says that it's a USB hub. I believe the information is redundant, and 
there should be a patch to remove it. Greg? :)

> ./root/pci0/00:07.2/usb_bus/00
> 
> 9. Contrary to PCI we enumerate the busses apparently
> by one dir level and not a suffix on the usb prefix.

Yes, the directory names are bus-specific identifiers for the device. It's 
up to the bus enumerator to determine what they are, and really don't make 
any sense outside of the bus context. 

> ./root/pci0/00:07.1/ata@00
> ./root/pci0/00:07.1/ata@00/sd@0,0
> ./root/pci0/00:07.1/ata@00/sd@0,0/power
> ./root/pci0/00:07.1/ata@00/sd@0,0/name
> ./root/pci0/00:07.1/ata@00/power
> ./root/pci0/00:07.1/ata@00/name
> 
> Here I'm trying to fit the whole in some kind of
> physical view. I did sneak in the sd instead of
> hd in the futile hope that SCSI will pick up the same
> name. And I buy in to the idea of separating
> the enumeratin for the naming by a @.
> This way one has only to enumerate the
> dir only and no room for possible ambiguity is present.

ata@00 is the controller, right? And sd@0,0 is the first disk on the first
channel?? You don't need the former. It's already present as PCI device
00:07.1, and you shouldn't have a duplicate entry. 

sd@0,0 can simply be 0,0 (though I don't personally like commas). You 
don't really _need_ any more context in there, since it's implied by your 
location in the tree.

> But it was entierly behind me how to fit this
> in to the sheme other sd@4,0:h,raw
> OS-es are using. And finally how would one fit this in to the
> partitioning shemes? For the system aprtitions are simply
> block devices hanging off the corresponding block device.

Partitions are purely logical entities on a physical disk. They have no 
presence in the physical device tree. 

> However we can see that the driver filesystem is
> inconsistant on the kind of enumeration it should
> provide. See the colon in sd@0,0 and the whole subdir
> crazyness... So do we distingish different devices by a subdir?
> Or do we do it by an unique enumeration suffix?

I don't understand your question. Yes enumeration is inconsistent, because 
it's dependent on the bus-supplied ID. 

> And last but not least: I still don't see any kind
> of abstraction there which would allow to easly enumerate
> for example all disks in the system.

It doesn't exist yet. Disks are a device class. When a disk driver 
discovers a disk, it will register it with the disk class. The class 
will then enumerate the disk. 

> However a simple major number range for disks 1 to 16000 would
> be ideal. And I bet that at some (not too distant) day we will
> simple have to reassign those numbers and be done.

Sure. Once device class supports materializes, classes will register and
can be assigned a dynamic major number even (if they don't already have
one). As devices (and partitions) are discovered, we can assign minor
numbers (dynamically!), and call /sbin/hotplug to notify userspace of the
discovery. It can use that information to create device nodes based on 
user-defined policy. 

[ Yes, that is similar to what devfs does, but there are several distinct 
differences... ]

I imagine we'll have a lot to discuss in Ottawa...

	-pat

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Patrick Mochel napisał:
>>But:
>>
>>1. There was the mistake of using different major numbers
>>for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).
>>
>>2. Then came devfs along and promised to slove this problem.
>>    But people still complained about not beeing ablve to boot, after
>>    I changed the registration name for IDE devices from "ide" to "ata".
>>    This showed nicely that devfs doesn't cut it. It's useless for
>>    the purpose of unification of access methods apparently.
>>
>>3. Now comes driverfs, which is basically a Solaris driver tree clone and
>>    *repeats* the same errors as 1. and 2.:
> 
> 
> driverfs is not a Solaris driver tree clone. Sure, it's similar, but I 
> assure no inspiaration was derived from Solaris. The same is true for the 
> Windows Driver Model (though bits of inspiration may have filtered into 
> the initial driver tree from WDM via the ACPI people).

Yes that's the pitty :-).

> driverfs does not care about major and minor numbers (yet). 
> 
> driverfs does not attempt to replace the /dev hierarchy.
> 
> That said, driverfs will use major/minor numbers in the future, but it
> will not care about what they are or who owns them. It will also offer a
> solution to the device naming problem (like devfs), and provide a 
> mechanism for maintaining /dev compatability. But, I'm foreshadowing. 

Irony by someone remembering the days devfs wasn't in the main
kernel tree and who was against it:
I tought devfs already solves those problems...


> You mean e.g. ./bus/pci/drivers/ ? I don't think it's useless at all. It 
> provides a mechanism for drivers to export attributes specific to the 
> drivers themselves (and not specific to a particular device). For example, 
> if you want to turn on debugging on the fly in the e100 driver, it could 
> export a 'debug' file, which the user could toggle. It would turn on 
> debugging for the entire driver on the fly. 

Interface on the heap phenomena. If someone writing a driver wished to have
this he could have registered some sysctl already. Becouse
this is precisely the interface fitting the purpose you describe.

> It likely has a module parameter to do the same thing. But, that parameter 
> is not available if you statically compile it into the kernel. And, module 
> parameters are not tweakable on the fly. 

See above - sysctl.

> Rusty and I are talking at the kernel workshop on Monday about parameters.  
> One of the topics is where module parameters leave off and driverfs starts
> up. It would be really really nice to unify the representation of these
> types of parameters. 

Indeed yes but it doesn't have to be done under the umbrella of
driverfs.

> Plus, something that is easy to do is create symlinks in the drivers' 
> directory to the devices in the physical hierarchy for the devices it's 
> driving. 

??


>>The bus suffix. is useless for any purpose I can imagine.
>>Which kind of view is the above supposed to present?
> 
> 
> It's the 'bus' view. Each bus should have a struct bus_type object that it 
> registers on startup. (See the documentation I sent out a couple of weeks 
> ago). It's then inserted into a flat list of bus types. 
> 
> Each bus keeps a list of devices and drivers. These lists are moved to the 
> struct bus_type for centralized management. 
> 
> Everything is exported via driverfs because it's easy to do so, and 
> because it can potentially be very useful. 
> 
> 
>>./root
>>
>>2. What is this root prefix good for?!
> 
> 
> Every system has the concept of a 'root' device. It's a virtual device 
> that doresn't physically exist. It's the start of the device tree. 

That's called /. BTW. If anything I'm missing there is the
representation of the very first BUS out there: CPU!!!

>>./root/pci0
>>
>>3. Solaris is separating the name and enumeration part by @ for
>>good reaons.
> 
> 
> 'pci0' is the bus ID of the first PCI bridge. Devices that exist on the 
> board itself and not on a peripheral bus don't have a standard for bus 
> IDs. So, I went with <canonical name><instance number>. I thought it was 
> pretty clear what it meant...

Yes and the *@* should be there to separate naming from enumeration part.
However I see in the above hierarchy no clear mandate for
where enumeration does happen - dir name subdirs named 0, 1, 2, 3,

>>./root/pci0/00:0c.1
>>./root/pci0/00:0c.1/resources

> I don't want driverfs to end up like procfs with the random formatting
> problem. I want driverfs files to be ASCII-only files with one value per
> file. This cannot be programmatically enforced, so we must rely on social
> engineering to enforce it. 

Forget it. I have warned against those problems even before /proc
became mandatory. You see now where we are. You are just moving
the arbitrary part away from the content to the fs name level.

> [ Also, the resources file also violates the second rule, since it's an 
> array of information, but I don't know any better way to represent this. ]

You see: ascii files are *evil* not just due to buffer overrun attacks.

> driverfs files are named attribute pairs, where the name of the attribute 
> is the name of the file, and the value is the contents. I've talked with 
> people before about making them even easier to create, read, and write, in 
> ways that enforce one value of a specific type to be exported. (I.e. 
> making them very restrictive). Someday...
> 
> 
>>./root/pci0/00:0c.1/irq
>>
>>5. This is showing that the resources file above is useless, becouse
>>I would rather love to consider irq as a resource.
> 
> 
> Sure, but it's a separate field. 
> 
> 
>>./root/pci0/00:0c.1/power
>>./root/pci0/00:0c.1/name
>>
>>6. The /name is entierly redundant logically to the fact that we
>>have already a unique path to the device. For "pretty" printing
>>we have userspace. For PCI it's for example repeating the
>>ID info found already by lspci.
> 
> 
> Sure. But, we already have the information in struct device. Instead of 
> using lspci, lsusb, lsfoo to ascertain the name, you can just cat the name 
> file for any device on the system. (Though, I basically agree with the 
> premise that that information doesn't need to be in the kernel in the 
> first place)

Argument frequently enough repeated by the advertisers of
the /proc mess... The kernel should be what it's name says -
just the kernel of the things and not the all for everything.

>>./root/pci0/00:07.2/usb_bus
>>
>>7. What is the _bus? suffix good for? How does this releate
>>to the /bus hierarchy?
> 
> 
> It says that it's a USB hub. I believe the information is redundant, and 
> there should be a patch to remove it. Greg? :)
> 
> 
>>./root/pci0/00:07.2/usb_bus/00
>>
>>9. Contrary to PCI we enumerate the busses apparently
>>by one dir level and not a suffix on the usb prefix.

You see I understood that pci0 is for the first bridge.
And you see that in comparision to /proc you are moving
the "arbitrary" part just from the file level to the directory
level.

Once reason I advertize for short names is the fact
that they will prevent people psychologicall from inventing
names like:

/devices/pci0/..../my_beloved_toy_device_which_....


> Yes, the directory names are bus-specific identifiers for the device. It's 
> up to the bus enumerator to determine what they are, and really don't make 
> any sense outside of the bus context. 
> 
> 
>>./root/pci0/00:07.1/ata@00
>>./root/pci0/00:07.1/ata@00/sd@0,0
>>./root/pci0/00:07.1/ata@00/sd@0,0/power
>>./root/pci0/00:07.1/ata@00/sd@0,0/name
>>./root/pci0/00:07.1/ata@00/power
>>./root/pci0/00:07.1/ata@00/name
>>
>>Here I'm trying to fit the whole in some kind of
>>physical view. I did sneak in the sd instead of
>>hd in the futile hope that SCSI will pick up the same
>>name. And I buy in to the idea of separating
>>the enumeratin for the naming by a @.
>>This way one has only to enumerate the
>>dir only and no room for possible ambiguity is present.
> 
> 
> ata@00 is the controller, right? And sd@0,0 is the first disk on the first
> channel?? You don't need the former. It's already present as PCI device
> 00:07.1, and you shouldn't have a duplicate entry. 
> 
> sd@0,0 can simply be 0,0 (though I don't personally like commas). You 
> don't really _need_ any more context in there, since it's implied by your 
> location in the tree.

I would love to distingish between device types sd - disk
sr - -CD-ROM DVD or whatever.
Please note that you have only one single PCI device but from
the physical perspecitve two buses hanging down from it called
channels (The ribbon between the disk and controller).
So a ATA host chip controller is basically even in reality
a PCI to ISA bus bridge. For example it's quite common
in notebooks to use the second ATA channel precisely as a bridge
between the host PCI and ISA on the expander....
Just forget that there is usually only a master and slave
on this bus please.

> Partitions are purely logical entities on a physical disk. They have no 
> presence in the physical device tree. 

Device drivers are purely logical entities of the kernel. They have
no presence in the physical device tree.

But they have a presence in /dev/ and are the entity we act on.

>>However we can see that the driver filesystem is
>>inconsistant on the kind of enumeration it should
>>provide. See the colon in sd@0,0 and the whole subdir
>>crazyness... So do we distingish different devices by a subdir?
>>Or do we do it by an unique enumeration suffix?

> I imagine we'll have a lot to discuss in Ottawa...

Yeep. I'm looking forward to it. Let's count the ARM CPUs attached
to my notebook after some real beer :-).

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

Re: [PATCH] /proc/scsi/map

[Martin Dalecki]

Użytkownik Patrick Mochel napisał:
>>But:
>>
>>1. There was the mistake of using different major numbers
>>for SCSI and IDE/ATAPI devices. (disk and CD-ROM are the most striking).
>>
>>2. Then came devfs along and promised to slove this problem.
>>    But people still complained about not beeing ablve to boot, after
>>    I changed the registration name for IDE devices from "ide" to "ata".
>>    This showed nicely that devfs doesn't cut it. It's useless for
>>    the purpose of unification of access methods apparently.
>>
>>3. Now comes driverfs, which is basically a Solaris driver tree clone and
>>    *repeats* the same errors as 1. and 2.:
> 
> 
> driverfs is not a Solaris driver tree clone. Sure, it's similar, but I 
> assure no inspiaration was derived from Solaris. The same is true for the 
> Windows Driver Model (though bits of inspiration may have filtered into 
> the initial driver tree from WDM via the ACPI people).

Yes that's the pitty :-).

> driverfs does not care about major and minor numbers (yet). 
> 
> driverfs does not attempt to replace the /dev hierarchy.
> 
> That said, driverfs will use major/minor numbers in the future, but it
> will not care about what they are or who owns them. It will also offer a
> solution to the device naming problem (like devfs), and provide a 
> mechanism for maintaining /dev compatability. But, I'm foreshadowing. 

Irony by someone remembering the days devfs wasn't in the main
kernel tree and who was against it:
I tought devfs already solves those problems...


> You mean e.g. ./bus/pci/drivers/ ? I don't think it's useless at all. It 
> provides a mechanism for drivers to export attributes specific to the 
> drivers themselves (and not specific to a particular device). For example, 
> if you want to turn on debugging on the fly in the e100 driver, it could 
> export a 'debug' file, which the user could toggle. It would turn on 
> debugging for the entire driver on the fly. 

Interface on the heap phenomena. If someone writing a driver wished to have
this he could have registered some sysctl already. Becouse
this is precisely the interface fitting the purpose you describe.

> It likely has a module parameter to do the same thing. But, that parameter 
> is not available if you statically compile it into the kernel. And, module 
> parameters are not tweakable on the fly. 

See above - sysctl.

> Rusty and I are talking at the kernel workshop on Monday about parameters.  
> One of the topics is where module parameters leave off and driverfs starts
> up. It would be really really nice to unify the representation of these
> types of parameters. 

Indeed yes but it doesn't have to be done under the umbrella of
driverfs.

> Plus, something that is easy to do is create symlinks in the drivers' 
> directory to the devices in the physical hierarchy for the devices it's 
> driving. 

??


>>The bus suffix. is useless for any purpose I can imagine.
>>Which kind of view is the above supposed to present?
> 
> 
> It's the 'bus' view. Each bus should have a struct bus_type object that it 
> registers on startup. (See the documentation I sent out a couple of weeks 
> ago). It's then inserted into a flat list of bus types. 
> 
> Each bus keeps a list of devices and drivers. These lists are moved to the 
> struct bus_type for centralized management. 
> 
> Everything is exported via driverfs because it's easy to do so, and 
> because it can potentially be very useful. 
> 
> 
>>./root
>>
>>2. What is this root prefix good for?!
> 
> 
> Every system has the concept of a 'root' device. It's a virtual device 
> that doresn't physically exist. It's the start of the device tree. 

That's called /. BTW. If anything I'm missing there is the
representation of the very first BUS out there: CPU!!!

>>./root/pci0
>>
>>3. Solaris is separating the name and enumeration part by @ for
>>good reaons.
> 
> 
> 'pci0' is the bus ID of the first PCI bridge. Devices that exist on the 
> board itself and not on a peripheral bus don't have a standard for bus 
> IDs. So, I went with <canonical name><instance number>. I thought it was 
> pretty clear what it meant...

Yes and the *@* should be there to separate naming from enumeration part.
However I see in the above hierarchy no clear mandate for
where enumeration does happen - dir name subdirs named 0, 1, 2, 3,

>>./root/pci0/00:0c.1
>>./root/pci0/00:0c.1/resources

> I don't want driverfs to end up like procfs with the random formatting
> problem. I want driverfs files to be ASCII-only files with one value per
> file. This cannot be programmatically enforced, so we must rely on social
> engineering to enforce it. 

Forget it. I have warned against those problems even before /proc
became mandatory. You see now where we are. You are just moving
the arbitrary part away from the content to the fs name level.

> [ Also, the resources file also violates the second rule, since it's an 
> array of information, but I don't know any better way to represent this. ]

You see: ascii files are *evil* not just due to buffer overrun attacks.

> driverfs files are named attribute pairs, where the name of the attribute 
> is the name of the file, and the value is the contents. I've talked with 
> people before about making them even easier to create, read, and write, in 
> ways that enforce one value of a specific type to be exported. (I.e. 
> making them very restrictive). Someday...
> 
> 
>>./root/pci0/00:0c.1/irq
>>
>>5. This is showing that the resources file above is useless, becouse
>>I would rather love to consider irq as a resource.
> 
> 
> Sure, but it's a separate field. 
> 
> 
>>./root/pci0/00:0c.1/power
>>./root/pci0/00:0c.1/name
>>
>>6. The /name is entierly redundant logically to the fact that we
>>have already a unique path to the device. For "pretty" printing
>>we have userspace. For PCI it's for example repeating the
>>ID info found already by lspci.
> 
> 
> Sure. But, we already have the information in struct device. Instead of 
> using lspci, lsusb, lsfoo to ascertain the name, you can just cat the name 
> file for any device on the system. (Though, I basically agree with the 
> premise that that information doesn't need to be in the kernel in the 
> first place)

Argument frequently enough repeated by the advertisers of
the /proc mess... The kernel should be what it's name says -
just the kernel of the things and not the all for everything.

>>./root/pci0/00:07.2/usb_bus
>>
>>7. What is the _bus? suffix good for? How does this releate
>>to the /bus hierarchy?
> 
> 
> It says that it's a USB hub. I believe the information is redundant, and 
> there should be a patch to remove it. Greg? :)
> 
> 
>>./root/pci0/00:07.2/usb_bus/00
>>
>>9. Contrary to PCI we enumerate the busses apparently
>>by one dir level and not a suffix on the usb prefix.

You see I understood that pci0 is for the first bridge.
And you see that in comparision to /proc you are moving
the "arbitrary" part just from the file level to the directory
level.

Once reason I advertize for short names is the fact
that they will prevent people psychologicall from inventing
names like:

/devices/pci0/..../my_beloved_toy_device_which_....


> Yes, the directory names are bus-specific identifiers for the device. It's 
> up to the bus enumerator to determine what they are, and really don't make 
> any sense outside of the bus context. 
> 
> 
>>./root/pci0/00:07.1/ata@00
>>./root/pci0/00:07.1/ata@00/sd@0,0
>>./root/pci0/00:07.1/ata@00/sd@0,0/power
>>./root/pci0/00:07.1/ata@00/sd@0,0/name
>>./root/pci0/00:07.1/ata@00/power
>>./root/pci0/00:07.1/ata@00/name
>>
>>Here I'm trying to fit the whole in some kind of
>>physical view. I did sneak in the sd instead of
>>hd in the futile hope that SCSI will pick up the same
>>name. And I buy in to the idea of separating
>>the enumeratin for the naming by a @.
>>This way one has only to enumerate the
>>dir only and no room for possible ambiguity is present.
> 
> 
> ata@00 is the controller, right? And sd@0,0 is the first disk on the first
> channel?? You don't need the former. It's already present as PCI device
> 00:07.1, and you shouldn't have a duplicate entry. 
> 
> sd@0,0 can simply be 0,0 (though I don't personally like commas). You 
> don't really _need_ any more context in there, since it's implied by your 
> location in the tree.

I would love to distingish between device types sd - disk
sr - -CD-ROM DVD or whatever.
Please note that you have only one single PCI device but from
the physical perspecitve two buses hanging down from it called
channels (The ribbon between the disk and controller).
So a ATA host chip controller is basically even in reality
a PCI to ISA bus bridge. For example it's quite common
in notebooks to use the second ATA channel precisely as a bridge
between the host PCI and ISA on the expander....
Just forget that there is usually only a master and slave
on this bus please.

> Partitions are purely logical entities on a physical disk. They have no 
> presence in the physical device tree. 

Device drivers are purely logical entities of the kernel. They have
no presence in the physical device tree.

But they have a presence in /dev/ and are the entity we act on.

>>However we can see that the driver filesystem is
>>inconsistant on the kind of enumeration it should
>>provide. See the colon in sd@0,0 and the whole subdir
>>crazyness... So do we distingish different devices by a subdir?
>>Or do we do it by an unique enumeration suffix?

> I imagine we'll have a lot to discuss in Ottawa...

Yeep. I'm looking forward to it. Let's count the ARM CPUs attached
to my notebook after some real beer :-).

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> That's called /. BTW. If anything I'm missing there is the
> representation of the very first BUS out there: CPU!!!

And if you have four cpus, two of them having southbridge with PCI?
You might make cpu%d the root....
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[sullivan]

On Thu, Jun 20, 2002 at 01:12:08PM -0700, Patrick Mochel wrote:
<snip>
> 
> Sure. Once device class supports materializes, classes will register and
> can be assigned a dynamic major number even (if they don't already have
> one). As devices (and partitions) are discovered, we can assign minor
> numbers (dynamically!), and call /sbin/hotplug to notify userspace of the
> discovery. It can use that information to create device nodes based on 
> user-defined policy. 
> 
<snip>

The driverfs patch for SCSI that was recently posted was the kernel portion of 
a device naming project that is intended to support all devices, at least the 
ones that implement to driverfs in a standard way. There are three items that
IMHO should be considered as part of the standard set that driverfs requires:

1. device type - It appears that Pat is heading down this path with the class
	type support so maybe this is a no brainer. Currently the scsi
	driverfs provides a "type" file to contain this info. The current
	strings used are taken from the scsi_device_types[] but should be
	replaced with the system wide device types that driverfs will provide.

2. uid - Since topology and discovery order of hardware can change, the
	driverfs path names to a device are also subject to change. To
	easily identify a device I think it's important that the driverfs
	bus implementations be responsible for create a unique identifier.

	Since each bus and the devices attached to it will have varying
	capabilities for identifying themselves the contents for this file
	should probably be a variable length string.

	Even for older devices that can't do a great job of providing info to
	uniquely identify themselves, the driverfs tree provides the nice
	topological context to fall back upon that allows at least as
	good of a job to be done as we do today.

	The scsi patch currently creates uid info from the INQUIRY evpd pages
	and makes it available in the name file. I would prefer to see a
	new standard uid file and let the name file contain a descriptive 
	(non-unique) name.

3. kdev - To create/manage/interface with the device node we need to know the
 	kdev.

Because of coldplugging this information should be available in each driverfs
device directory. Also, adding the driverfs path name on /sbin/hotplug
events and allowing the consumer to retrieve the info from the filesystem might
help simplify some of these implementations too.

The devnaming utility that is based on this strategy is available at
http://www-124.ibm.com/devreg/ 

I'd welcome any thoughts or suggestions.	

- Mike Sullivan

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> The driverfs patch for SCSI that was recently posted was the kernel portion of 
> a device naming project that is intended to support all devices, at least the 
> ones that implement to driverfs in a standard way. There are three items that
> IMHO should be considered as part of the standard set that driverfs requires:
> 
> 1. device type - It appears that Pat is heading down this path with the class
> 	type support so maybe this is a no brainer. Currently the scsi
> 	driverfs provides a "type" file to contain this info. The current
> 	strings used are taken from the scsi_device_types[] but should be
> 	replaced with the system wide device types that driverfs will provide.

Yes, they are pretty much the same thing. 

> 2. uid - Since topology and discovery order of hardware can change, the
> 	driverfs path names to a device are also subject to change. To
> 	easily identify a device I think it's important that the driverfs
> 	bus implementations be responsible for create a unique identifier.
> 
> 	Since each bus and the devices attached to it will have varying
> 	capabilities for identifying themselves the contents for this file
> 	should probably be a variable length string.
> 
> 	Even for older devices that can't do a great job of providing info to
> 	uniquely identify themselves, the driverfs tree provides the nice
> 	topological context to fall back upon that allows at least as
> 	good of a job to be done as we do today.
> 
> 	The scsi patch currently creates uid info from the INQUIRY evpd pages
> 	and makes it available in the name file. I would prefer to see a
> 	new standard uid file and let the name file contain a descriptive 
> 	(non-unique) name.

Yes, I agree. UUIDs are needed to do any type of persistant naming (well). 
As you say, there are varying ways for determining the UUID, and some ways 
may not be present for some devices. It will be up to the various driver 
levels to determine if they can determine a better UUID than higher level 
layers.

For example, PCI by default doesn't have very good unique information. 
About the best it can do is something like munging together:

	<bus><device><function><class><subclass>

If that device is a network card, the class driver can set the UUID of the 
device to the MAC of the device. (Network cards won't be named, but it's 
only an example). (Or, the label of a disk). 

Further, if the device driver knows an even better way to ID the device, 
e.g. via a serial number on the device, it can do so. 

Some buses and their driver won't have to worry, since that information is 
mandatory in the devices. 

> 3. kdev - To create/manage/interface with the device node we need to know the
>  	kdev.

Sure. I don't have objections to this. It will likely become obvious that 
we need this later on...

> Because of coldplugging this information should be available in each
> driverfs device directory. Also, adding the driverfs path name on
> /sbin/hotplug events and allowing the consumer to retrieve the info
> from the filesystem might help simplify some of these implementations
> too.

This information should be exported, I agree. But, we could theoretically 
achieve a state where every device discovered gets a call to 
/sbin/hotplug. 

[ With initramfs, we could have the rootfs partition mounted before we 
start probing for any devices. As long as that had /sbin/hotplug, and the 
means and policy to name devices, it should work. ]

	-pat

[PATCH] driverfs scsi for 2.5.24

[Douglas Gilbert]

[-- Attachment #1: Type: text/plain, Size: 10160 bytes --]

Attached is Mike Sullivan's driverfs patch which was released
on June 21. It has been minimally changed so it applies to
lk 2.5.24 . 

Here are Mike's original notes:

Mike Sullivan wrote:
> 
> The driverfs patch for SCSI that was recently posted was the kernel portion of
> a device naming project that is intended to support all devices, at least the
> ones that implement to driverfs in a standard way. There are three items that
> IMHO should be considered as part of the standard set that driverfs requires:
> 
> 1. device type - It appears that Pat is heading down this path with the class
>         type support so maybe this is a no brainer. Currently the scsi
>         driverfs provides a "type" file to contain this info. The current
>         strings used are taken from the scsi_device_types[] but should be
>         replaced with the system wide device types that driverfs will provide.
> 
> 2. uid - Since topology and discovery order of hardware can change, the
>         driverfs path names to a device are also subject to change. To
>         easily identify a device I think it's important that the driverfs
>         bus implementations be responsible for create a unique identifier.
> 
>         Since each bus and the devices attached to it will have varying
>         capabilities for identifying themselves the contents for this file
>         should probably be a variable length string.
> 
>         Even for older devices that can't do a great job of providing info to
>         uniquely identify themselves, the driverfs tree provides the nice
>         topological context to fall back upon that allows at least as
>         good of a job to be done as we do today.
> 
>         The scsi patch currently creates uid info from the INQUIRY evpd pages
>         and makes it available in the name file. I would prefer to see a
>         new standard uid file and let the name file contain a descriptive
>         (non-unique) name.
> 
> 3. kdev - To create/manage/interface with the device node we need to know the
>         kdev.
> 
> Because of coldplugging this information should be available in each driverfs
> device directory. Also, adding the driverfs path name on /sbin/hotplug
> events and allowing the consumer to retrieve the info from the filesystem might
> help simplify some of these implementations too.
> 
> The devnaming utility that is based on this strategy is available at
> http://www-124.ibm.com/devreg/
> 
> I'd welcome any thoughts or suggestions.

It will probably take a few iterations before we get
close to an "approved" naming model :-)
 
So people have some idea what this patch generates, here
is my system's "/proc/scsi/scsi" followed by a "du -a"
at the top of the driverfs tree:

$ cat /proc/scsi/scsi
Attached devices: 
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: FUJITSU  Model: MAM3184MP        Rev: 0105
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 09 Lun: 00
  Vendor: SEAGATE  Model: ST318451LW       Rev: 0003
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: Linux    Model: scsi_debug       Rev: 0003
  Type:   Direct-Access                    ANSI SCSI revision: 03

$ du -a
...
0       ./bus/usb
0       ./bus/scsi/drivers/sr
0       ./bus/scsi/drivers/sg
0       ./bus/scsi/drivers/sd		# empty directory
0       ./bus/scsi/drivers
0       ./bus/scsi/devices/3:0:0:0:disc  # symlinks across to "root" subtree
0       ./bus/scsi/devices/3:0:0:0:gen
0       ./bus/scsi/devices/3:0:0:0
0       ./bus/scsi/devices/1:0:9:0:gen
0       ./bus/scsi/devices/1:0:0:0:gen
0       ./bus/scsi/devices/1:0:9:0:p7
0       ./bus/scsi/devices/1:0:9:0:p6
0       ./bus/scsi/devices/1:0:9:0:p5
0       ./bus/scsi/devices/1:0:9:0:p4
0       ./bus/scsi/devices/1:0:9:0:p3
0       ./bus/scsi/devices/1:0:9:0:p2
0       ./bus/scsi/devices/1:0:9:0:p1
0       ./bus/scsi/devices/1:0:9:0:disc
0       ./bus/scsi/devices/1:0:0:0:p7
0       ./bus/scsi/devices/1:0:0:0:p6
0       ./bus/scsi/devices/1:0:0:0:p5
0       ./bus/scsi/devices/1:0:0:0:p4
0       ./bus/scsi/devices/1:0:0:0:p3
0       ./bus/scsi/devices/1:0:0:0:p2
0       ./bus/scsi/devices/1:0:0:0:p1
0       ./bus/scsi/devices/1:0:0:0:disc
0       ./bus/scsi/devices/1:0:9:0
0       ./bus/scsi/devices/1:0:0:0
0       ./bus/scsi/devices
0       ./bus/scsi
....
0       ./bus/pci/devices/00:0c.1 # symlinks, Tekram dual controller
0       ./bus/pci/devices/00:0c.0
....
0       ./bus/pci
0       ./bus

# scsi_debug "virtual" host bubbles to the top of "root"
# hierarchy because it has no "parent" bus type (i.e. it
# isn't pci). Why is the <h,c,t,l> given twice?
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/kdev
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/type
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/power
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc/name  # S1234Linuxdisc
0       ./root/scsi3/3:0:0:0/3:0:0:0:disc
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/kdev
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/type
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/power
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen/name   # S1234Linuxgeneric
0       ./root/scsi3/3:0:0:0/3:0:0:0:gen
0       ./root/scsi3/3:0:0:0/type
0       ./root/scsi3/3:0:0:0/power
0       ./root/scsi3/3:0:0:0/name  # S1234Linux
0       ./root/scsi3/3:0:0:0
0       ./root/scsi3/power
0       ./root/scsi3/name          # scsi_debug, Version: 1.59 ....
0       ./root/scsi3
0       ./root/pci0/00:0d.0/resources
0       ./root/pci0/00:0d.0/irq
.... 
0       ./root/pci0/00:0c.1/scsi2/power
0       ./root/pci0/00:0c.1/scsi2/name   # sym-2.1.16a
0       ./root/pci0/00:0c.1/scsi2
0       ./root/pci0/00:0c.1/resources
0       ./root/pci0/00:0c.1/irq
0       ./root/pci0/00:0c.1/power
0       ./root/pci0/00:0c.1/name      # PCI device 1000:0020
0       ./root/pci0/00:0c.1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen/name
              # S3CC01TTG000071033QEASEAGATEgeneric
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:gen
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7/name
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p7
...
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1/name
              # S3CC01TTG000071033QEASEAGATEpart1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:p1
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc/name
              # S3CC01TTG000071033QEASEAGATEdisc 
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/1:0:9:0:disc
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/type
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/power
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0/name
              # S3CC01TTG000071033QEASEAGATE
0       ./root/pci0/00:0c.0/scsi1/1:0:9:0
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen/name
              # SUKS0P1B009PFFUJITSUgeneric
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:gen
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7/name
              # SUKS0P1B009PFFUJITSUpart7
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p7
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p6/kdev
....
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1/name
              # SUKS0P1B009PFFUJITSUpart1
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:p1
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/kdev
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc/name
              # SUKS0P1B009PFFUJITSUdisc
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/1:0:0:0:disc
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/type
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/power
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0/name
              # SUKS0P1B009PFFUJITSU
0       ./root/pci0/00:0c.0/scsi1/1:0:0:0
0       ./root/pci0/00:0c.0/scsi1/power
0       ./root/pci0/00:0c.0/scsi1/name
              # sym-2.1.16a
0       ./root/pci0/00:0c.0/scsi1
0       ./root/pci0/00:0c.0/resources
0       ./root/pci0/00:0c.0/irq
0       ./root/pci0/00:0c.0/power
0       ./root/pci0/00:0c.0/name
0       ./root/pci0/00:0c.0
....
0       ./root/pci0/00:04.1/ata@01/power
0       ./root/pci0/00:04.1/ata@01/name  # ATA/ATAPI Host-Channel
0       ./root/pci0/00:04.1/ata@01


It would be useful if Martin could show us one of his ATA
driverfs trees.

Patrick mentioned that we can soon expect these directories:
     /driverfs/class/disk
     /driverfs/class/tape
     /driverfs/class/cd  (or cd-dvd, or ...)
and perhaps
     /driverfs/class/misc
for those nasty devices (e.g. tape robots and storage enclosures)
that need pass through drivers like sg. 
The "/driverfs/class/disk"
directory would contain all attached disks (i.e.
ATA, SCSI, USB ...) with enumerated names (i.e.
"disk0", "disk1"). These enumerated names would be symlinks
to the device.


I'll start with one suggestion: perhaps "kdev" could
be replaced by two files: "major" and "minor".

Comments?

Doug Gilbert

[-- Attachment #2: scsi-driverfs_2524.diff.gz --]
[-- Type: application/x-gzip, Size: 8809 bytes --]

Re: [PATCH] driverfs scsi for 2.5.24

[James Bottomley]

Actually, the patch already went into Linus' BK tree and will be in 2.5.25.

dougg@torque.net said:
> It will probably take a few iterations before we get close to an
> "approved" naming model :-) 

That's part of the reason for putting it in early...

> I'll start with one suggestion: perhaps "kdev" could be replaced by
> two files: "major" and "minor". 

I think kdev belongs in the (not yet implemented) class driver, doesn't it? 
(Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done 
at the class level, the kdev policy will be set globally.

I think the partition `name' file should reflect the partition UUID if one 
exists, and that the disc `name' file should be mutable by root so we can do 
fixups (from hotplug) for the exceptional devices that don't have a proper 
unique name.

As far as numeric enumerations go, I think we can begin to move away from 
them.  Everything that has a parent bus no longer needs a host number since it 
has a unique position in the device tree.  The mid-layer itself thinks of host 
enumerations in terms of a linked list, so it doesn't need the number either.  
This way, we should be able to finesse all our complex host addition/removal 
numbering issues that plague 2.4.

I also think that target numbers only make sense when they exist in reality 
(like on a parallel bus).  quite a few fibre channel drivers do internal 
remapping to real target identifiers; I see no reason why they can't just 
expose the ASCII representation of what they use for the device on the bus to 
driverfs now.

LUNs are probably still usefully numeric, but it would be nice to use the 
filesystem hierarchy to represent the SCSI-3 LUN hierarchy.

The key to using driverfs efficiently is to remember that it simply exposes to 
the user how the SCSI subsystem sees the device tree.  Therefore, once we have 
the simplest useful device tree inside SCSI, that will be the way the user 
sees it as well.

James

Re: [PATCH] driverfs scsi for 2.5.24

[Douglas Gilbert]

James Bottomley wrote:
> 
> Actually, the patch already went into Linus' BK tree and will be in 2.5.25.
> 
> dougg@torque.net said:
> > It will probably take a few iterations before we get close to an
> > "approved" naming model :-)
> 
> That's part of the reason for putting it in early...
> 
> > I'll start with one suggestion: perhaps "kdev" could be replaced by
> > two files: "major" and "minor".
> 
> I think kdev belongs in the (not yet implemented) class driver, doesn't it?
> (Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done
> at the class level, the kdev policy will be set globally.
> 
> I think the partition `name' file should reflect the partition UUID if one
> exists, and that the disc `name' file should be mutable by root so we can do
> fixups (from hotplug) for the exceptional devices that don't have a proper
> unique name.

So will partitions only be visible in the "class" subtree?
I still want to see an example of what disks (and their
partitions) will look like in the "class" subtree.

Patrick Mochel's 3rd July class.txt file gave a networking example:
	/devices/class/net/eth
	/devices/class/net/eth/eth1
	/devices/class/net/eth/eth1/physical  # symlink
	/devices/class/net/eth/eth0
	/devices/class/net/eth/eth0/physical
So "net" is the class and "eth" is the subclass under which
there is an enumeration. Given a "disk" class does it have
any subclasses? [Answering "scsi" and "ata" would probably not 
be politically correct.]
 
> As far as numeric enumerations go, I think we can begin to move away from
> them.  Everything that has a parent bus no longer needs a host number since it
> has a unique position in the device tree.  The mid-layer itself thinks of host
> enumerations in terms of a linked list, so it doesn't need the number either.
> This way, we should be able to finesse all our complex host addition/removal
> numbering issues that plague 2.4.

Enumerations seem to be moving to a different level.
 
> I also think that target numbers only make sense when they exist in reality
> (like on a parallel bus).  quite a few fibre channel drivers do internal
> remapping to real target identifiers; I see no reason why they can't just
> expose the ASCII representation of what they use for the device on the bus to
> driverfs now.

According to SAM-2, Annex A, Table A.3 an FCP-2 target
identifier is 3 bytes of binary. The problems arise with
SRP (infiniband), iSCSI and SBP-3 (iee1394). That table
suggests that 262 bytes of UTF-8 (ascii) is the worst case
for an iSCSI initiator port identifier.
In SAM-2 parlance this would suggest an array like:
	uint8_t port_id[262];

> LUNs are probably still usefully numeric, but it would be nice to use the
> filesystem hierarchy to represent the SCSI-3 LUN hierarchy.

Patrick Mansfield seemed uncomfortable about foregoing
the existing numeric luns. So perhaps we could keep the
existing:
	uint32_t lun;
and add
	uint8_t lu_id[8];

That way we keep what REPORT LUNS tells us, and for the
vast majority of cases are able to generate a numeric
lun from it.

> The key to using driverfs efficiently is to remember that it simply exposes to
> the user how the SCSI subsystem sees the device tree.  Therefore, once we have
> the simplest useful device tree inside SCSI, that will be the way the user
> sees it as well.

When I tried to place some of the scsi_debug lower level driver
parameters into driverfs I found nowhere to put them. It seems
that the Scsi_Host_Template structure should have a
"struct device_driver scsi_driverfs_lldriver" entry in it.
The Scsi_Device_Template structure has a "struct device_driver"
entry, why not Scsi_Host_Template?

>From an OO perspective, "struct device" is a base class from
which Scsi_Device and Scsi_Host are derived while
"struct device_driver" is a base class from which
Scsi_Device_Template and Scsi_Host_Template are derived.
Patrick Mochel's documents seem to be explaning a virtual
destructor mechanism as well.

Doug Gilbert

Re: [PATCH] driverfs scsi for 2.5.24

[Patrick Mochel]

> So will partitions only be visible in the "class" subtree?
> I still want to see an example of what disks (and their
> partitions) will look like in the "class" subtree.

Do you need partitions visible from driverfs at all? They are simply
logical entities on the physical device. What do they get in driverfs,
direcetories? (Sorry, I still haven't looked at the patch; I don't
actually have any SCSI devices any more. But, I will look at it soon. I 
promise.) 

> Patrick Mochel's 3rd July class.txt file gave a networking example:
> 	/devices/class/net/eth
> 	/devices/class/net/eth/eth1
> 	/devices/class/net/eth/eth1/physical  # symlink
> 	/devices/class/net/eth/eth0
> 	/devices/class/net/eth/eth0/physical
> So "net" is the class and "eth" is the subclass under which
> there is an enumeration. Given a "disk" class does it have
> any subclasses? [Answering "scsi" and "ata" would probably not 
> be politically correct.]

I wouldn't think that you would need subclasses for disks. You may have 
multiple interfaces for each disk (there's a few recent messages on lkml 
about this), but that's another story. 

> > LUNs are probably still usefully numeric, but it would be nice to use the
> > filesystem hierarchy to represent the SCSI-3 LUN hierarchy.
> 
> Patrick Mansfield seemed uncomfortable about foregoing
> the existing numeric luns. So perhaps we could keep the
> existing:
> 	uint32_t lun;
> and add
> 	uint8_t lu_id[8];

Out of curiosity, why do you guys use types and not u32, u8, etc? 

> > The key to using driverfs efficiently is to remember that it simply exposes to
> > the user how the SCSI subsystem sees the device tree.  Therefore, once we have
> > the simplest useful device tree inside SCSI, that will be the way the user
> > sees it as well.
...
> >From an OO perspective, "struct device" is a base class from
> which Scsi_Device and Scsi_Host are derived while
> "struct device_driver" is a base class from which
> Scsi_Device_Template and Scsi_Host_Template are derived.
> Patrick Mochel's documents seem to be explaning a virtual
> destructor mechanism as well.

Yes. Both statements are right on. You SCSI guys are so good.

	-pat

Re: [PATCH] driverfs scsi for 2.5.24

[Patrick Mochel]

On Wed, 3 Jul 2002, James Bottomley wrote:

> Actually, the patch already went into Linus' BK tree and will be in 2.5.25.
> 
> dougg@torque.net said:
> > It will probably take a few iterations before we get close to an
> > "approved" naming model :-) 
> 
> That's part of the reason for putting it in early...
> 
> > I'll start with one suggestion: perhaps "kdev" could be replaced by
> > two files: "major" and "minor". 
> 
> I think kdev belongs in the (not yet implemented) class driver, doesn't it? 
> (Pat?), so we shouldn't be doing anything to expose it in SCSI.  If it's done 
> at the class level, the kdev policy will be set globally.

Yes. However, if you guys can use it now, go ahead and implement it where
you see fit. Once the infrasructure is in place, we can push it upwards to
the generic structure. 

> I think the partition `name' file should reflect the partition UUID if one 
> exists, and that the disc `name' file should be mutable by root so we can do 
> fixups (from hotplug) for the exceptional devices that don't have a proper 
> unique name.

Dave Brownell (USB guy) brought this up a few days ago. The 'name' field 
is intended to be a user-friendly ascii description of the device. I'm 
considering changing the name to 'descr' to end all confusion. 

I intend to create a field to represent the unique identifier (maybe 
'uuid'). Again, if you guys need something like that, go ahead and put it 
in the SCSI-specific structure, and let it pushed upwards when the time 
comes. 

	-pat

Re: [PATCH] /proc/scsi/map

[Oliver Xymoron]

On Thu, 20 Jun 2002, Patrick Mochel wrote:

> > But it was entierly behind me how to fit this
> > in to the sheme other sd@4,0:h,raw
> > OS-es are using. And finally how would one fit this in to the
> > partitioning shemes? For the system aprtitions are simply
> > block devices hanging off the corresponding block device.
>
> Partitions are purely logical entities on a physical disk. They have no
> presence in the physical device tree.

As I raised elsewhere in this thread, the distinction between physical and
logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
to SCSI-over-Fibre Channel, except that rather than using an embedded FC
stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
disk/tape/whatever as a local device. Ergo, it ought to show up in the
device tree so that it can be discovered in the same way. But where?

This is only one step (the SCSI midlayer) removed from the logical devices
created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
that again, ought to be discoverable in the same way as all other block
devices. Perhaps we need root/{virtual,logical}?

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Fri, 2002-06-21 at 15:33, Oliver Xymoron wrote:
> On Thu, 20 Jun 2002, Patrick Mochel wrote:
> 
> > > But it was entierly behind me how to fit this
> > > in to the sheme other sd@4,0:h,raw
> > > OS-es are using. And finally how would one fit this in to the
> > > partitioning shemes? For the system aprtitions are simply
> > > block devices hanging off the corresponding block device.
> >
> > Partitions are purely logical entities on a physical disk. They have no
> > presence in the physical device tree.
> 
> As I raised elsewhere in this thread, the distinction between physical and
> logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> disk/tape/whatever as a local device. Ergo, it ought to show up in the
> device tree so that it can be discovered in the same way. But where?
> 
> This is only one step (the SCSI midlayer) removed from the logical devices
> created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
> that again, ought to be discoverable in the same way as all other block
> devices. Perhaps we need root/{virtual,logical}?
> 

The interaction between iSCSI & driverfs does pose an interesting
problem:

On one hand I tend to lead toward the view of a physical device. 
The reason being that there will never be a distinction as far as the
kernel is concerned (other than driverfs of course) that a SCSI upper
level driver (hopefully soon to be a personality driver) using a iSCSI
Initiator low-level driver is not really a physical host. 

On the other hand there is the obvious fact that an iSCSI initiator
driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
etc, is out of the question.  There is a real need for a solution to
handle virtual devices (as stated your previous message) that are not
assoicated with any physical connectors.  

Not being too fimilar with driverfs,  what are the options with regard
to virtual devices as things currently stand without tainting the
elegant tree that is provides?
				
				Nicholas Bellinger

Re: [PATCH] /proc/scsi/map

[Douglas Gilbert]

Nick Bellinger wrote:
> 
> On Fri, 2002-06-21 at 15:33, Oliver Xymoron wrote:
> > On Thu, 20 Jun 2002, Patrick Mochel wrote:
> >
> > > > But it was entierly behind me how to fit this
> > > > in to the sheme other sd@4,0:h,raw
> > > > OS-es are using. And finally how would one fit this in to the
> > > > partitioning shemes? For the system aprtitions are simply
> > > > block devices hanging off the corresponding block device.
> > >
> > > Partitions are purely logical entities on a physical disk. They have no
> > > presence in the physical device tree.
> >
> > As I raised elsewhere in this thread, the distinction between physical and
> > logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> > to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> > stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> > disk/tape/whatever as a local device. Ergo, it ought to show up in the
> > device tree so that it can be discovered in the same way. But where?
> >
> > This is only one step (the SCSI midlayer) removed from the logical devices
> > created by partitioning, LVM, NBD, MD, loopback, ramdisk and the like,
> > that again, ought to be discoverable in the same way as all other block
> > devices. Perhaps we need root/{virtual,logical}?
> >
> 
> The interaction between iSCSI & driverfs does pose an interesting
> problem:
> 
> On one hand I tend to lead toward the view of a physical device.
> The reason being that there will never be a distinction as far as the
> kernel is concerned (other than driverfs of course) that a SCSI upper
> level driver (hopefully soon to be a personality driver) using a iSCSI
> Initiator low-level driver is not really a physical host.
> 
> On the other hand there is the obvious fact that an iSCSI initiator
> driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> etc, is out of the question.  There is a real need for a solution to
> handle virtual devices (as stated your previous message) that are not
> assoicated with any physical connectors.
> 
> Not being too fimilar with driverfs,  what are the options with regard
> to virtual devices as things currently stand without tainting the
> elegant tree that is provides?

iSCSI introduces some other issues. The SCSI subsystem has
a 4 byte target (port) identifier at the moment. However Annex A
of the SAM-2 draft ( http://www.t10.org ) indicates that it should
be 258 bytes for iSCSI (and 11 bytes for ieee1394). For iSCSI the
target port identifier is a WWUI plus a 2 byte target portal group 
tag. A WWUI looks like:
  com.disk-vendor.diskarrays.sn.45678

Also the SCSI subsystem has tended to hide the the initiator's
own identifier (this is usually id 7 on the SCSI parallel bus).
For iSCSI it may be worthwhile to make the initiator port 
identifier visible in driverfs.

There is also the case where you want a box to appear to
the network as an iSCSI target. In this case once a iSCSI
login is complete you might want to represent the initiator
in the driverfs tree. For iSCSI, the initiator port identifier 
is a WWUI plus a 6 byte "inititator session id" for a total
of 262 bytes.

So the "target id" we put in driverfs could have one of
these suggested formats:
   <number>              - 0 to 1 for ATA
   <number>              - 0 to 15 for SCSI parallel interface
   <number>              - 24 bit number for fibre channel
   <EUI 64+discovery_id> - ieee1394
   <???>                 - usb (mass storage + scanner)
   <WWUI> ":" <num>      - iSCSI   [something better than ":"?]


We should also be moving towards 8 byte luns which in one
descriptor format are a 4 level hierarchy (2 bytes at each
level).

Doug Gilbert

Re: [PATCH] /proc/scsi/map

[Nick Bellinger]

On Sat, 2002-06-22 at 13:41, Douglas Gilbert wrote:
> > 
> > The interaction between iSCSI & driverfs does pose an interesting
> > problem:
> > 
> > On one hand I tend to lead toward the view of a physical device.
> > The reason being that there will never be a distinction as far as the
> > kernel is concerned (other than driverfs of course) that a SCSI upper
> > level driver (hopefully soon to be a personality driver) using a iSCSI
> > Initiator low-level driver is not really a physical host.
> > 
> > On the other hand there is the obvious fact that an iSCSI initiator
> > driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> > etc, is out of the question.  There is a real need for a solution to
> > handle virtual devices (as stated your previous message) that are not
> > assoicated with any physical connectors.
> > 
> > Not being too fimilar with driverfs,  what are the options with regard
> > to virtual devices as things currently stand without tainting the
> > elegant tree that is provides?
> 
> iSCSI introduces some other issues. The SCSI subsystem has
> a 4 byte target (port) identifier at the moment. However Annex A
> of the SAM-2 draft ( http://www.t10.org ) indicates that it should
> be 258 bytes for iSCSI (and 11 bytes for ieee1394). For iSCSI the
> target port identifier is a WWUI plus a 2 byte target portal group 
> tag. A WWUI looks like:
>   com.disk-vendor.diskarrays.sn.45678

Yikes, 4 bytes?  Is there any special considerations bumping up the to
the maximum for an iSCSI Initiator SCSI port name of 264 bytes?

> 
> Also the SCSI subsystem has tended to hide the the initiator's
> own identifier (this is usually id 7 on the SCSI parallel bus).
> For iSCSI it may be worthwhile to make the initiator port 
> identifier visible in driverfs.
> 

Agreed.

> There is also the case where you want a box to appear to
> the network as an iSCSI target. In this case once a iSCSI
> login is complete you might want to represent the initiator
> in the driverfs tree. For iSCSI, the initiator port identifier 
> is a WWUI plus a 6 byte "inititator session id" for a total
> of 262 bytes.
> 

Now this would be interesting,  although I am not sure how useful
this would be if the user cannot see the entire iSCSI network or if this
would not be better left to userspace.  But of course that is out of the
scope of driverfs.

> So the "target id" we put in driverfs could have one of
> these suggested formats:
>    <number>              - 0 to 1 for ATA
>    <number>              - 0 to 15 for SCSI parallel interface
>    <number>              - 24 bit number for fibre channel
>    <EUI 64+discovery_id> - ieee1394
>    <???>                 - usb (mass storage + scanner)
>    <WWUI> ":" <num>      - iSCSI   [something better than ":"?]
> 

What does the ":" <num> represent?  Would not each <WWUI> directory
contain the devices which are currently in use from that iSCSI target
node?  

> 
> We should also be moving towards 8 byte luns which in one
> descriptor format are a 4 level hierarchy (2 bytes at each
> level).

<nod>
> 
> Doug Gilbert
> 
Thanks,
		Nicholas Bellinger			

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> So the "target id" we put in driverfs could have one of
> these suggested formats:
>    <number>              - 0 to 1 for ATA
>    <number>              - 0 to 15 for SCSI parallel interface
>    <number>              - 24 bit number for fibre channel
>    <EUI 64+discovery_id> - ieee1394
>    <???>                 - usb (mass storage + scanner)
>    <WWUI> ":" <num>      - iSCSI   [something better than ":"?]

In the physical device tree, what's wrong with setting the name to 
something simple, like 'iscsi0', etc. All you're looking for is 
a locally unique ID. 

You need a globally unique ID to do persitant attribute setting and 
restoration, including naming. When /sinb/hotplug gets a call to name the 
device, it can look up the GUID to determine what to name the device.

	-pat

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

On Fri, 21 Jun 2002, Oliver Xymoron wrote:

> On Thu, 20 Jun 2002, Patrick Mochel wrote:
> 
> > > But it was entierly behind me how to fit this
> > > in to the sheme other sd@4,0:h,raw
> > > OS-es are using. And finally how would one fit this in to the
> > > partitioning shemes? For the system aprtitions are simply
> > > block devices hanging off the corresponding block device.
> >
> > Partitions are purely logical entities on a physical disk. They have no
> > presence in the physical device tree.
> 
> As I raised elsewhere in this thread, the distinction between physical and
> logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> disk/tape/whatever as a local device. Ergo, it ought to show up in the
> device tree so that it can be discovered in the same way. But where?

An iSCSI device is a physical device; it just doesn't reside on the local 
system. We should represent the device in some physical form, since the 
logical class mappings do/will assume a mapping to a physical device. 

These devices are essentially children of the network via which they're 
attached. When devices are discovered, I'm assuming you can derive the 
network device through which you're communicating, so you can get enforce 
the ancestral relationship. 

You want the ancestral relationship for several reasons. You'd wouldn't 
power down such a device on PM transitions or during shutdown, but you 
would stop I/O transactions. The drivers for these devices should recogize 
it's a remote device and handlethis. And, if you were to remove the bridge 
device (the network card, etc), you want the devices behind it and their 
logical mappings to go away gracefully.

Mulitpath devices, which you could easily have with multiple routes to the 
same IP address, are another issue that must be addressed. It hasn't yet, 
but we're getting closer...

	-pat

Re: [PATCH] /proc/scsi/map

[Oliver Xymoron]

On Tue, 25 Jun 2002, Patrick Mochel wrote:

>
> On Fri, 21 Jun 2002, Oliver Xymoron wrote:
>
> > On Thu, 20 Jun 2002, Patrick Mochel wrote:
> >
> > > > But it was entierly behind me how to fit this
> > > > in to the sheme other sd@4,0:h,raw
> > > > OS-es are using. And finally how would one fit this in to the
> > > > partitioning shemes? For the system aprtitions are simply
> > > > block devices hanging off the corresponding block device.
> > >
> > > Partitions are purely logical entities on a physical disk. They have no
> > > presence in the physical device tree.
> >
> > As I raised elsewhere in this thread, the distinction between physical and
> > logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
> > to SCSI-over-Fibre Channel, except that rather than using an embedded FC
> > stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
> > disk/tape/whatever as a local device. Ergo, it ought to show up in the
> > device tree so that it can be discovered in the same way. But where?
>
> An iSCSI device is a physical device; it just doesn't reside on the local
> system. We should represent the device in some physical form, since the
> logical class mappings do/will assume a mapping to a physical device.
>
> These devices are essentially children of the network via which they're
> attached. When devices are discovered, I'm assuming you can derive the
> network device through which you're communicating, so you can get enforce
> the ancestral relationship.

As you note below, it can be available on multiple interfaces. For maximal
confusion, it could be available on a regular NIC and an iSCSI offload
NIC, making it appear as a regular SCSI device (a case to bear in mind,
but one I doubt can be dealt with cleanly).

> You want the ancestral relationship for several reasons. You'd wouldn't
> power down such a device on PM transitions or during shutdown, but you
> would stop I/O transactions. The drivers for these devices should recogize
> it's a remote device and handlethis. And, if you were to remove the bridge
> device (the network card, etc), you want the devices behind it and their
> logical mappings to go away gracefully.

Ok, so what's your take on: NBD (iSCSI without all the SCSI crap),
software RAID, LVM, ramdisk, partitions (a degenerate case of volume
management), loopback, and filesystems. All but the last are block devices
that want to be treated just like disks and will want to know about things
like PM transitions, etc. Filesystems haven't made it into the tree
because we've got that info elsewhere and we've been assuming they're
leafnodes, but if we put loopback devices on top of them, that's no longer
the case. It'd be cleaner globally if this were all explicit in the driver
tree.

> Mulitpath devices, which you could easily have with multiple routes to the
> same IP address, are another issue that must be addressed. It hasn't yet,
> but we're getting closer...

Good to know it's on the radar..

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] /proc/scsi/map

[Patrick Mochel]

> > You want the ancestral relationship for several reasons. You'd wouldn't
> > power down such a device on PM transitions or during shutdown, but you
> > would stop I/O transactions. The drivers for these devices should recogize
> > it's a remote device and handlethis. And, if you were to remove the bridge
> > device (the network card, etc), you want the devices behind it and their
> > logical mappings to go away gracefully.
> 
> Ok, so what's your take on: NBD (iSCSI without all the SCSI crap),
> software RAID, LVM, ramdisk, partitions (a degenerate case of volume
> management), loopback, and filesystems. All but the last are block devices
> that want to be treated just like disks and will want to know about things
> like PM transitions, etc. Filesystems haven't made it into the tree
> because we've got that info elsewhere and we've been assuming they're
> leafnodes, but if we put loopback devices on top of them, that's no longer
> the case. It'd be cleaner globally if this were all explicit in the driver
> tree.

This is a topic that has come up several times in the last couple days in 
Ottawa. I don't promise to have a complete solution, but this what I have 
so far:

You have two things: a physical device and a number of logical interfaces
to communicate with the device. iSCSI devices, local disks, video devices, 
mice, and joysticks are all physical devices and deserve a place in the 
device tree. 

RAID, LVM, DRI, and the input layer are all logical interfaces to physical 
devices. The drivers are the conduit between the logical and the physical. 
Drivers register devices with the logical interfcaces as their attached. 
It's up to the driver to register with the interfaces, which they already 
do. If registration gets generalized and centralized, you get internal 
linkage between the interfaces and the devices. This is essentially the 
device class voodoo that I've been talking about. 

Concerning power management, if we have a list of interfaces, and each had 
a suspend callback, you could notify the interfaces before you walked the 
device tree. Maybe this could take care of verifying the devices can 
suspend and failing if it's doing I/O that's too important to stop. 

[ We could also create a swap interface that we skip over when we notify 
these interfaces. Then we walk the tree and save state to the swap 
devices. Then, tell the swap devices to suspend, which can notify the 
devices to actually go to sleep....maybe..]

	-pat

Re: [PATCH] /proc/scsi/map

[Pavel Machek]

Hi!

> [ We could also create a swap interface that we skip over when we notify 
> these interfaces. Then we walk the tree and save state to the swap 
> devices. Then, tell the swap devices to suspend, which can notify the 
> devices to actually go to sleep....maybe..]

No.

swsusp works like this

	stop all devices
	save state
	atomically copy memory into my_big_buffer
	start all devices
	write my_big_buffer into swap
	poweroff

It does not need explicit knowledge of where swap is. And I believe it
is reasonable that way.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 8963 bytes --]

Hi Linus,

On Thu, Jun 20, 2002 at 08:34:40AM -0700, Linus Torvalds wrote:
> On Thu, 20 Jun 2002, Kurt Garloff wrote:
> > Look at /proc/scsi/scsi: The information is useful for the reader who wants
> > to know what devices he has and were found by the SCSI subsystem.
> 
> I would rephrase that as "the information is only useful to find devices
> found by the SCSI midlayer".

But finding is limited to get a list of manufacturer/model names and their
current CBTU location. You can't make up a device node from that. Only with
a lot of code you arrive at semi-reliable information.

> And my point is that you don't make it any better. Your patch perpetuates
> this lopsided world-view that people should care. THAT is the fundamental
> part that I don't like, because it drags us down for the future.

Actually, with the important exception of IDE disks, most devices are SCSI
in some way, meaning that they understand the SCSI command set. ATAPI
devices are, USB-storage is, IEEE1394 devices are ... so it is not as
restricted as it may seem.
So our consolidated driver structure will IMHO look like this
 
    0        1              2            3

  disk -->  IDE-disk --> IDE mid(?)--> IDE-low
       \-> SCSI-disk --> SCSI-mid  --> SCSI-low
                     |             \-> FC-low
                     \-> USB-mid   --> USB-low
		     \-> FW-mid    --> FW-low
		     \-> pport-mid --> pport-low
		      ....

  cdrom -> SCSI-cd   --> SCSI-mid  --> SCSI-low
                     \-> IDE-mid   --> IDE-low
		      ....
 
   
The drivers at column 0 would implement the interface to userspace vie the
device nodes. column 1 would generate the commands. column 2 would more or
less be some helper/transport layer whereas 3 would talk to the hardware.
And probably there will be some generalized "linux" command set being used
between 0 and 1, which would further down the chain be converted to the real
low-level commands. (We actually already have such a thing for block devs.)
So at level 1 there would be a more general "linux cmd set to XXX cmd set
converter".

Now, userspace should really not care what sort of device is hiding behind a
"disk" device, except that we 
(1) want to be able to identify and find back a device
   (a) by a path to it                  and/or
   (b) by a unique hardware identifier  and/or
   (c) by its content (a label on it)
(2) may want to be able to send low-level (SCSI mostly) commands for
    configuration  to inquire speical information, or to do things where no
    kernel driver support exists, such as scanning or writing CDs.
    For SCSI-like devices, we always want to use sg for this, IMHO,
    as open() on a sg device is without side-effects and works reliably.

For the above, we only have partial solutions, currently.
(1a) The /driverfs path is exposing how a device is connected
     (Similar to the CBTU tuple, but more general and more reliable.)
     Unfortunately, this is 2.5 only.
(1b) We would need to get some WWN or serial number from the device.
     Unfortunately, not all devices have such a thing; currently
     we need userspace tools (see (2)) to collect such info or
     rely on the low-level driver
(1c) UUID and LVM make use of this, but that's a disk-only thing.
(2)  We currently have no relation between e.g. a disk and a sg device, so
     we lost. We can try to collect this info in userspace programs, but
     it's tedious, error prone and not reliable at this moment.

I hope we will have good solutions for all of these in future.

The reason why we want at least (1a) and one of (1b)/(1c) is that we can
have a device connected to a computer more than once (multipathing).

Some devices offer more than one interface; if a kernel-driver for writing
CDs would exist, we would have both a writer and cdrom driver attached to it.
The fact that it's the same piece of hardware also would need to be reflected
in some way. 

For now, lots of devices hook into the the SCSI subsystem, and what I'm
trying to get is a solution for (2) which also enable userspace solutions
for (1b).

[...]
> I will bet you that there are more IDE CD-RW's out there than there are
> SCSI devices. The fact that people use ide-scsi to write to them is a
> hopefully very temporary situation, and the command interface is going
> to move to a higher layer.

They use SCSI commands, so you will want to offer an interface for
applications to send SCSI commands, unless you want somebody to write a
kernel driver to support CD writing.
This would in my "SCSI-centric world-view" also be a SCSI interface, though
maybe not based on nowadays SCSI mid-layer code.

> At which point your SCSI-centric world-view now became a total failure, as
> it no longer shows up most of the devices that can write CD's or DVD's any
> more.
> 
> Sure, it will still continue to show "what devices were found by the SCSI
> midlayer". But user applications will have to scan other stuff, and find
> the IDE-specific stuff, and then whatever else is out there.
> 
> See the problem?

I imagine that we will continue to allow userspace to send raw commands to
devices, as we won't be able nor willing to support every device type fully
by kernel drivers.
These raw commands will be SCSI commands for most devices.
I imagined, that we register all those devices within some subsystem
which would be a revised, generalized and probably thinner SCSI subsystem.

> If, on the other hand, you try to take the bull by the horns and realize
> that the notion of "searching for devices" has nothing to do with SCSI at
> _all_, you may find yourself with more work on your hands, but on the
> other hand, wouldn't it be just so _nice_ to be able to do
> 
> 	find /devices -name cd-rw
> 
> to find all cd-rw's in the system?

Which makes we wonder whether we'll present devices by their attachment path
or by their type or both ....
But yes, it would be nice.

> Does it work that way now? Absolutely not. 
> But most of the infrastructure is actually there today. Wouldn't it
> be _nice_ if after the CD-writing app has found all cd-rw's, it just opens
> them, and the kernel will automatically open the right device (whether it
> is a scsi-generic one or a IDE one)?

See, I would both call SCSI devices. Just because you use a 40/80 pin IDE
cable and a somewhat different low-level protocol, it still understands
SCSI commands.

[...]
> > And completely useless for any program that wants to find a scanner,
> > CD-Writer, ... as there is no connection to the high-level drivers attached
> > to them.
> 
> I'm not disputing that.
> 
> However, I _am_ disputing that this should be done in some SCSI-centric
> way that works for SCSI but nothing else.

I would have imagined driver unification as making all devices that
understand SCSI commands to hook into some generalized and cleaned SCSI
subsystem.
Obviously your vision (or only naming?) is different.
How does it look like in your plans?

> When I want to find a CD-ROM, I don't want to worry about whether it is
> IDE or SCSI. I would
> 
> > But I still think the SCSI subsystem should report which SCSI (low-level)
> > device is mapped to what high-level driver.
> > Would you accept a patch that adds a line like
> >
> > Host: scsi3 Channel: 00 Id: 12 Lun: 00
> >   Vendor: IBM      Model: DPSS-336950N     Rev: S84D
> >   Type:   Direct-Access                    ANSI SCSI revision: 03
> >   Attached drivers: sg12(c:15:0c) sdf(b:08:50)
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > to /proc/scsi/scsi ?
> 
> That would be less offensive to me if only because it doesn't introduce a
> _new_ interface that is SCSI-only, it only extends on an old one. It makes
> no _technical_ difference, but I'd rather extend an old broken interface
> than introduce a totally new broken interface.

Please consider applying the attached patch which adds this line.

[...]
> > The CBTU tuple uniquely addresses a SCSI device in a running system.
> 
> Yes, but that's not enough. Other people are still asking for physical
> location, so let's try to fix two things with _one_ generic interface that
> is at least agnostic to how a device is connected to the kernel..

That would be the /dev/disks/0 ... N, /dev/cd/0 ... M, ... interface, if I
get you correctly. Instead of 0 ... N one might hope to have unique IDs.

But we would still need to find some way to allow extra information, like
the path there, sending low-level commands, ... as we'll never be able
(nor wanting) to push all into the kernel behind the "disk" interface, I
think ...

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #1.2: scsi-map-8.diff --]
[-- Type: text/plain, Size: 8535 bytes --]

diff -uNr linux-2.5.23-dj2/drivers/scsi/hosts.h linux-2.5.23-dj2-scsirephl/drivers/scsi/hosts.h
--- linux-2.5.23-dj2/drivers/scsi/hosts.h	Thu Jun 20 01:44:47 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/hosts.h	Thu Jun 20 18:54:10 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.23-dj2/drivers/scsi/osst.c linux-2.5.23-dj2-scsirephl/drivers/scsi/osst.c
--- linux-2.5.23-dj2/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/osst.c	Thu Jun 20 18:54:26 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.23-dj2/drivers/scsi/scsi_proc.c linux-2.5.23-dj2-scsirephl/drivers/scsi/scsi_proc.c
--- linux-2.5.23-dj2/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/scsi_proc.c	Thu Jun 20 18:52:55 2002
@@ -260,6 +260,10 @@
 
 	int x, y = *size;
 	extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
+	char nm[16];
+	kdev_t kdev;
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
 
 	y = sprintf(buffer + len,
 	     "Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n  Vendor: ",
@@ -295,7 +299,24 @@
 		y += sprintf(buffer + len + y, " CCS\n");
 	else
 		y += sprintf(buffer + len + y, "\n");
+	
+	/* Report high level devices attached */
+	y += sprintf (buffer + len + y, "  Attached drivers:");
 
+	while (att && sd_t) {
+		if (sd_t->find_kdev) {
+			if (!(sd_t->find_kdev(scd, nm, &kdev))) {
+				y += sprintf(buffer + len + y,
+					     " %s(%c:%02x:%02x)",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     MAJOR(kdev), MINOR(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
 	*size = y;
 	return;
 }
diff -uNr linux-2.5.23-dj2/drivers/scsi/sd.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sd.c
--- linux-2.5.23-dj2/drivers/scsi/sd.c	Thu Jun 20 01:44:48 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sd.c	Thu Jun 20 18:54:43 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.23-dj2/drivers/scsi/sg.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sg.c
--- linux-2.5.23-dj2/drivers/scsi/sg.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sg.c	Thu Jun 20 18:54:51 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2632,6 +2635,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.23-dj2/drivers/scsi/sr.c linux-2.5.23-dj2-scsirephl/drivers/scsi/sr.c
--- linux-2.5.23-dj2/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/sr.c	Thu Jun 20 18:54:59 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.23-dj2/drivers/scsi/st.c linux-2.5.23-dj2-scsirephl/drivers/scsi/st.c
--- linux-2.5.23-dj2/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.23-dj2-scsirephl/drivers/scsi/st.c	Thu Jun 20 18:56:18 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] /proc/scsi/map

[Linus Torvalds]

On Thu, 20 Jun 2002, Kurt Garloff wrote:
>
> Actually, with the important exception of IDE disks, most devices are SCSI
> in some way

Don't be silly.

You appear to have a very disk-centric world view, and you seem to ignore
that even in disks, the large majority is IDE, and with SCSI prices not
coming down, that's going to be only more and more true.

Also, most disk devices are using SCSI _command_sets_. But that does not
translate to "using the SCSI mid-layer".

> So our consolidated driver structure will IMHO look like this

The way it seems to be going right now is:

 - stage 1: minor/major -> "queue + index" mapping
   (only done at "open()" time, the internal kernel is trying to get rid
   of most of the major/minor stuff)

 - stage 2: ll_rw_block.c, ioctl.c: insert command on queue.

   Yes, this layer builds up SCSI commands, but it doesn't actually have
   anything to do with the SCSI midlayer.

 - stage 3: driver takes it off the queue and executes the thing.

In short, what is happening is that the SCSI mid-layer to some degree
becomes _less_ relevant, exactly because the SCSI _command_ structure has
gotten so universal that that part is moved up one layer into the generic
part.

Which means that things like ide-scsi etc just don't make any sense any
more. Your assumption that SCSI-cd would take over the IDE layer is just
_wrong_. It's going the other way. There shouldn't be any real difference
between "disk" and "cdrom", you just send commands down the queue.

> Now, userspace should really not care what sort of device is hiding behind a
> "disk" device, except that we
> (1) want to be able to identify and find back a device
>    (a) by a path to it                  and/or
>    (b) by a unique hardware identifier  and/or
>    (c) by its content (a label on it)

Absolutely.

> (2) may want to be able to send low-level (SCSI mostly) commands for
>     configuration  to inquire speical information, or to do things where no
>     kernel driver support exists, such as scanning or writing CDs.
>     For SCSI-like devices, we always want to use sg for this, IMHO,
>     as open() on a sg device is without side-effects and works reliably.

I think we should get _away_ from those silly "sg" devices. The whole
notion that there are "sg" vs "sr" vs "sd" devices is a total bogosity,
and should just go away. What's the point of having those things? It only
confuses people.

We should open a disk device, and access it. Nothing else. The fact that
SCSI got the notion that sd/sr/sg are somehow different is just one of the
_problems_ in the SCSI layer. It's just a queue to send commands to
together with the data and the result, that's all it ever was.

(In other words, I kind of agree with your characterization that "we
should always use 'sg'" because clearly that's the closest of the SCSI
devices to the notion of a command queue. However, I think you've stared
at SCSI so long that you think that that split-up makes sense, when it
really doesn't).

> > I will bet you that there are more IDE CD-RW's out there than there are
> > SCSI devices. The fact that people use ide-scsi to write to them is a
> > hopefully very temporary situation, and the command interface is going
> > to move to a higher layer.
>
> They use SCSI commands, so you will want to offer an interface for
> applications to send SCSI commands, unless you want somebody to write a
> kernel driver to support CD writing.

SCSI commands != "SCSI midlayer".

The IDE driver is already moving into the direction that it just accepts a
command off the request queue.

That does _not_ mean that it has anything to do with the SCSI layer, quite
the reverse. It means that we're going _away_ from the SCSI layer, and
that ide-scsi becomes nothing but an embarrassing remnant of history.

		Linus

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

On Thu, Jun 20, 2002 at 08:32:09PM +0200, Kurt Garloff wrote:
> Please consider applying the attached patch which adds this line.

Updated patch (with MAJOR -> major correction) against 2.5.24 is here.

diff -uNr linux-2.5.24-dj1/drivers/scsi/hosts.h linux-2.5.24-dj1-scsirephl/drivers/scsi/hosts.h
--- linux-2.5.24-dj1/drivers/scsi/hosts.h	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/hosts.h	Fri Jun 21 08:22:27 2002
@@ -486,6 +486,7 @@
     void (*detach)(Scsi_Device *);
     int (*init_command)(Scsi_Cmnd *);     /* Used by new queueing code. 
                                            Selects command for blkdevs */
+    int (*find_kdev)(Scsi_Device *, char*, kdev_t*);  /* find back dev. */
 };
 
 void  scsi_initialize_queue(Scsi_Device * SDpnt, struct Scsi_Host * SHpnt);
diff -uNr linux-2.5.24-dj1/drivers/scsi/osst.c linux-2.5.24-dj1-scsirephl/drivers/scsi/osst.c
--- linux-2.5.24-dj1/drivers/scsi/osst.c	Wed Jun 19 04:11:54 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/osst.c	Fri Jun 21 08:22:27 2002
@@ -155,6 +155,7 @@
 static int osst_attach(Scsi_Device *);
 static int osst_detect(Scsi_Device *);
 static void osst_detach(Scsi_Device *);
+static int osst_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 struct Scsi_Device_Template osst_template =
 {
@@ -166,7 +167,8 @@
        detect:		osst_detect,
        init:		osst_init,
        attach:		osst_attach,
-       detach:		osst_detach
+       detach:		osst_detach,
+       find_kdev:	osst_find_kdev,
 };
 
 static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -5417,6 +5419,24 @@
 	return 0;
 }
 
+static int osst_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	OS_Scsi_Tape *ostp;
+	
+	if (sdp && sdp->type == TYPE_TAPE && osst_supports(sdp)) {
+		for (ostp = os_scsi_tapes[i = 0]; i < osst_template.dev_max;
+		     ostp = os_scsi_tapes[++i]) {
+			if (ostp && ostp->device == sdp) {
+				sprintf (nm, "osst%i", i);
+				*dev = mk_kdev(OSST_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int osst_attach(Scsi_Device * SDp)
 {
 	OS_Scsi_Tape * tpnt;
diff -uNr linux-2.5.24-dj1/drivers/scsi/scsi_proc.c linux-2.5.24-dj1-scsirephl/drivers/scsi/scsi_proc.c
--- linux-2.5.24-dj1/drivers/scsi/scsi_proc.c	Wed Jun 19 04:11:47 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/scsi_proc.c	Fri Jun 21 08:21:44 2002
@@ -260,6 +260,10 @@
 
 	int x, y = *size;
 	extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
+	char nm[16];
+	kdev_t kdev;
+	int att = scd->attached;
+	struct Scsi_Device_Template *sd_t = scsi_devicelist;
 
 	y = sprintf(buffer + len,
 	     "Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n  Vendor: ",
@@ -295,7 +299,24 @@
 		y += sprintf(buffer + len + y, " CCS\n");
 	else
 		y += sprintf(buffer + len + y, "\n");
+	
+	/* Report high level devices attached */
+	y += sprintf (buffer + len + y, "  Attached drivers:");
 
+	while (att && sd_t) {
+		if (sd_t->find_kdev) {
+			if (!(sd_t->find_kdev(scd, nm, &kdev))) {
+				y += sprintf(buffer + len + y,
+					     " %s(%c:%02x:%02x)",
+					     nm, (sd_t->blk? 'b': 'c'),
+					     major(kdev), minor(kdev));
+				--att;
+			}
+		}
+		sd_t = sd_t->next;
+	}
+
+	y += sprintf(buffer + len + y, "\n");
 	*size = y;
 	return;
 }
diff -uNr linux-2.5.24-dj1/drivers/scsi/sd.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sd.c
--- linux-2.5.24-dj1/drivers/scsi/sd.c	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sd.c	Fri Jun 21 08:22:27 2002
@@ -103,6 +103,7 @@
 static int sd_detect(Scsi_Device *);
 static void sd_detach(Scsi_Device *);
 static int sd_init_command(Scsi_Cmnd *);
+static int sd_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template sd_template = {
 	module:THIS_MODULE,
@@ -122,6 +123,7 @@
 	attach:sd_attach,
 	detach:sd_detach,
 	init_command:sd_init_command,
+	find_kdev:sd_find_kdev,
 };
 
 static void sd_rw_intr(Scsi_Cmnd * SCpnt);
@@ -285,6 +287,24 @@
 	}
 }
 
+static int sd_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_Disk *sdkp;
+	int dsk_nr;
+
+	if (sdp && (sdp->type == TYPE_DISK || sdp->type == TYPE_MOD)) {
+		for (dsk_nr = 0; dsk_nr < sd_template.dev_max; ++dsk_nr) {
+			sdkp = sd_dsk_arr[dsk_nr];
+			if (sdkp->device == sdp) {
+				sd_dskname(dsk_nr, nm);
+				*dev = MKDEV_SD(dsk_nr);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 /**
  *	sd_find_queue - yields queue associated with device
  *	@dev: kernel device descriptor (kdev_t)
diff -uNr linux-2.5.24-dj1/drivers/scsi/sg.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sg.c
--- linux-2.5.24-dj1/drivers/scsi/sg.c	Fri Jun 21 07:51:45 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sg.c	Fri Jun 21 08:22:27 2002
@@ -111,6 +111,7 @@
 static void sg_finish(void);
 static int sg_detect(Scsi_Device *);
 static void sg_detach(Scsi_Device *);
+static int sg_find_kdev(Scsi_Device *, char*, kdev_t*);
 
 static Scsi_Request * dummy_cmdp;	/* only used for sizeof */
 
@@ -120,6 +121,7 @@
 static struct Scsi_Device_Template sg_template =
 {
       module:THIS_MODULE,
+      name:"generic",
       tag:"sg",
       scsi_type:0xff,
       major:SCSI_GENERIC_MAJOR,
@@ -127,7 +129,8 @@
       init:sg_init,
       finish:sg_finish,
       attach:sg_attach,
-      detach:sg_detach
+      detach:sg_detach,
+      find_kdev:sg_find_kdev
 };
 
 
@@ -2674,6 +2677,37 @@
 }
 
 #ifdef CONFIG_PROC_FS
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    unsigned long iflags;
+    int err = 1; 
+
+    if (sdp && sg_dev_arr) {
+	int k;
+	read_lock_irqsave(&sg_dev_arr_lock, iflags);
+	for (k = 0; k < sg_template.dev_max; ++k) {
+	    if (sg_dev_arr[k] && sg_dev_arr[k]->device == sdp) {
+		sprintf (nm, "sg%i", k);
+	        *dev = sg_dev_arr[k]->i_rdev;
+		err = 0;
+		break;
+	    }
+	}
+	read_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+    }
+    return err;
+}
+#else
+/* Not needed without procfs support */
+static int sg_find_kdev(Scsi_Device* sdp, char *nm, kdev_t *dev)
+{
+    *nm = 0;
+    *kdev = NODEV;
+    return 1;
+}
+#endif
+
+#ifdef CONFIG_PROC_FS
 
 static struct proc_dir_entry * sg_proc_sgp = NULL;
 
diff -uNr linux-2.5.24-dj1/drivers/scsi/sr.c linux-2.5.24-dj1-scsirephl/drivers/scsi/sr.c
--- linux-2.5.24-dj1/drivers/scsi/sr.c	Wed Jun 19 04:11:50 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/sr.c	Fri Jun 21 08:22:27 2002
@@ -71,6 +71,8 @@
 
 static int sr_init_command(Scsi_Cmnd *);
 
+static int sr_find_kdev(Scsi_Device*, char*, kdev_t*);
+
 static struct Scsi_Device_Template sr_template =
 {
 	module:THIS_MODULE,
@@ -84,7 +86,8 @@
 	finish:sr_finish,
 	attach:sr_attach,
 	detach:sr_detach,
-	init_command:sr_init_command
+	init_command:sr_init_command,
+	find_kdev:sr_find_kdev,
 };
 
 Scsi_CD *scsi_CDs;
@@ -471,6 +474,23 @@
 	return 0;
 }
 
+static int sr_find_kdev(Scsi_Device *sdp, char* nm, kdev_t *dev)
+{
+	Scsi_CD *srp;
+	int i;
+	
+	if (sdp && (sdp->type == TYPE_ROM || sdp->type == TYPE_WORM)) {
+		for (srp = scsi_CDs, i = 0; i < sr_template.dev_max;
+		     ++i, ++srp) {
+			if (srp->device == sdp) {
+				sprintf(nm, "sr%i", i);
+				*dev = mk_kdev(SCSI_CDROM_MAJOR,i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
 
 void get_sectorsize(int i)
 {
diff -uNr linux-2.5.24-dj1/drivers/scsi/st.c linux-2.5.24-dj1-scsirephl/drivers/scsi/st.c
--- linux-2.5.24-dj1/drivers/scsi/st.c	Wed Jun 19 04:11:56 2002
+++ linux-2.5.24-dj1-scsirephl/drivers/scsi/st.c	Fri Jun 21 08:22:27 2002
@@ -148,6 +148,7 @@
 static int st_attach(Scsi_Device *);
 static int st_detect(Scsi_Device *);
 static void st_detach(Scsi_Device *);
+static int st_find_kdev(Scsi_Device*, char*, kdev_t*);
 
 static struct Scsi_Device_Template st_template = {
 	module:		THIS_MODULE,
@@ -157,7 +158,8 @@
 	major:		SCSI_TAPE_MAJOR, 
 	detect:		st_detect, 
 	attach:		st_attach, 
-	detach:		st_detach
+	detach:		st_detach,
+	find_kdev:	st_find_kdev
 };
 
 static int st_compression(Scsi_Tape *, int);
@@ -3760,6 +3762,24 @@
 	return;
 }
 
+static int st_find_kdev(Scsi_Device * sdp, char* nm, kdev_t *dev)
+{
+	int i;
+	Scsi_Tape *stp;
+
+	if (sdp && sdp->type == TYPE_TAPE && !st_incompatible(sdp)) {
+		for (stp = scsi_tapes[0], i = 0; i < st_template.dev_max;
+		     stp = scsi_tapes[++i]) {
+			if (stp && stp->device == sdp) {
+				sprintf(nm, "st%i", i);
+				*dev = mk_kdev(SCSI_TAPE_MAJOR, i);
+				return 0;
+			}
+		}
+	}
+	return 1;
+}
+
 static int __init init_st(void)
 {
 	validate_options();



Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

Re: [PATCH] /proc/scsi/map

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]

Hi Linus,

On Wed, Jun 19, 2002 at 10:03:16PM -0700, Linus Torvalds wrote:
> On Thu, 20 Jun 2002, Kurt Garloff wrote:
> > 
> > find attached a patch (against 2.5.23-dj2) to the SCSI subsystem which 
> > adds a file /proc/scsi/map, which provides a listing of SCSI devices,
> > enumerated by the CBTU/HCIL tuple and the high-level devices attached to
> > them. 
> 
> I really despise this.

Thanks for your feedback.

Actually, I think you want to address a different problem than I want to.

I do believe that the scsi subsystem does not expose enough information for
many things. 

Look at /proc/scsi/scsi: The information is useful for the reader who wants
to know what devices he has and were found by the SCSI subsystem.

And completely useless for any program that wants to find a scanner,
CD-Writer, ... as there is no connection to the high-level drivers attached
to them. Which means that all these programs basically contain their own
SCSI scanning code, which means opnening all sg devices and collecting the
information. I do not think that this is a good idea that a lot of userspace
programs need to do a lot of effort to get some information that could just
be exported by the kernel.

But I indeed had persistent naming in mind as well and mentioned it, so this
is probably why the discussion went that way.
scsidev, which I took over from Eric Youngdale some time ago, tries to
provide persistent naming for SCSI devices and suffers the problem, that
it can't work reliably, as open() of sr/st/osst devices can fail because
devices are already in use (-EBUSY) or have no medium inserted. (O_NONBLOCK
does not always help.) And it can take considerable time or cause unwanted
side-effects. 

You're right that just enumerating all scsi devices in a somewhat more
persistent way does not constitute a complete solution to the problem of
persistent naming of attached storage devices. That is something that would
need to be addressed at a higher level and not inside SCSI midlevel, of
course.

But I still think the SCSI subsystem should report which SCSI (low-level)
device is mapped to what high-level driver.
Would you accept a patch that adds a line like

Host: scsi3 Channel: 00 Id: 12 Lun: 00
  Vendor: IBM      Model: DPSS-336950N     Rev: S84D
  Type:   Direct-Access                    ANSI SCSI revision: 03
  Attached drivers: sg12(c:15:0c) sdf(b:08:50)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to /proc/scsi/scsi ?

Actually that was my first idea, but I was reluctant to change the format of
an existing file, as it might be parsed by existing code. 
But, given the uselessness of /proc/scsi/scsi for code, I guess that's
a small risk ... 

> It's just _wrong_ to have one file with a collection of devices in it, and 
> it is _doubly_ wrong when that one file
> 
>  - is limited to a (arbitrary) subset of the disks in your system

You mean all disks driven by the SCSI subsystem, right?

>  - has completely bogus information about "location" that has nothing to 
>    do with real life, yet pruports to be an "address" even though it 
>    obviously isn't.

The CBTU tuple uniquely addresses a SCSI device in a running system.
It's just not persistent against configuration changes, unfortunately.
But it's reported by /proc/scsi/scsi as well and therefore useful to
find back in map, IMHO.

[...]
> Either you enumerate things without any structure (like the current SCSI
> layer does: disk0, disk1, disk2 ...) or you give full their addresses.  
> Don't do the half-assed thing.

I would certainly like to see code at block layer that does provide the
infrastructure to see persistent names for all sort of attached devices,
especially disks.

> PLEASE don't add these kinds of SCSI-specific hacks, that are _useless_ to
> find other types of disks, and that makes no sense, and will not work for
> things like DAC960, for IDE, or for anything else that just ignores the 
> SCSI layer (even if it physically uses SCSI disks, like the DAC960 setup).

Please consider the possibility of adding the reporting of the attached
high-level drivers to /proc/scsi/scsi

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]