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 <[email protected]>, 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 <[email protected]>, 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 <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
Linux: SCSI, Security <[email protected]> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
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
>>>>> "Linus" == Linus Torvalds <[email protected]> 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
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 <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
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
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
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
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.
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.]
[email protected] 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
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
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
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
>
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
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 <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
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
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
[email protected] 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
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
[ 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
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
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.."
> 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
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.
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
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.
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 :-).
>>>>> "Linus" == Linus Torvalds <[email protected]> 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
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
> From: Linus Torvalds [mailto:[email protected]]
> 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).
ACPI DEVC NAMS ARNT USED FOR MUCH. WE CAN <ahem> lowercase them in driverfs
and not hurt anything. The _HID entries under them are the more useful
thing, generally.
;-)
Regards -- Andy
PS I don't know about the caps but iirc 4 char names were to make names
small and fixed length. This theoretically resulted in easier compares by
casting to u32s, and a slightly simpler interpreter. (hah)
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
>
>
>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.
>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.
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
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 <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
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
> 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
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
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.."
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 [...]
Absolutely! devicefs should be for anything that is simplified
by using the drivers/base rendezvous to eliminate that type of list
management which is repeated so many times in the kernel.
One thing that is very confusing about the current
drivers/base code is that "struct bus' really has nothing to do
with a bus. It should be called "struct device_type." For example,
sd_mod (scsi disk), sr_mod (scsi cdrom), and sg (scsi generic) are
all drivers for arbitrary scsi devices, regardless of whether
they are connected by scsi ribbon cable, usb, or whatever.
In the example of system partitions and raid, you could put a
struct device in struct gendisk and have the partitioning module
register themselves as drivers of that device type. That way, they
would automatically try to attach to each disk that had no
partitioning scheme attached (actually, I'd rather eliminate all
partitioning suppot from the kernel and just have the device
mapper make the partition devices under control of a user level
utility, similar to the way all of my systems have been running
for the past couple of years via partx).
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
> 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.
There are those who see the IP stack as a kind of logical bus ... :)
It's just not tied any specific hardware interface; it's "multipathed" in
some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0
would be wrong, since it can also be accessed through eth2.
Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup
for iSCSI devices? Using whatever physical addressing the kernel uses
there, which I assume wouldn't necessarily be restricted to ipv4. (And
not exposing physical network topology -- routing! -- in driverfs.)
On a related topic ... if driverfs is going to be providing a nice unique
ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for
Linus' behind-two-bridges case), why are people talking as if the SCSI
layer's arbitrary "controller number" should still be getting pushed as
part of user visible names?
That is, I'd sure hope the standard policy for assigning driverfs names
would avoid _all_ IDs that are derived from enumeration order. Otherwise
it'll be hard to store those names for (re)use by user mode tools.
To be sure, those IDs can still be exposed when needed, since in the
"very big picture" attribute-based names end up being the only really
scalable model. But putting unstable attributes into path names just
causes trouble. (Much like putting device types in path names.) If
they're really necessary (why?) driverfs makes it easy to expose them
in better ways.
- Dave
Hi,
On Sat, 22 Jun 2002, David Brownell wrote:
> Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup
> for iSCSI devices? Using whatever physical addressing the kernel uses
> there, which I assume wouldn't necessarily be restricted to ipv4.
iSCSI devices are uniqely identified by its name. An iSCSI device can be
reachable at multiple ip numbers or they can even change dynamically.
bye, Roman
On Sat, 2002-06-22 at 11:24, David Brownell wrote:
> > 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.
>
> There are those who see the IP stack as a kind of logical bus ... :)
> It's just not tied any specific hardware interface; it's "multipathed" in
> some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0
> would be wrong, since it can also be accessed through eth2.
>
> Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup
> for iSCSI devices? Using whatever physical addressing the kernel uses
> there, which I assume wouldn't necessarily be restricted to ipv4. (And
> not exposing physical network topology -- routing! -- in driverfs.)
>
>
Giving the IP stack its own directory (leaf?) under driverfs root sounds
interesting enough and could have some potential uses, but in the case
of iSCSI there are a few problems:
iSCSI Names (aka: iSCSI Qualified Names or IEEE EUI-64 names ) are world
wide unique and are intended to stay with the iSCSI Node throughout its
lifetime, regardless of IP/HBA/NIC/etc changes. Also an iSCSI session
can include multiple TCP connections with each different IP addresses,
so the format of $DRIVERFS/net/[email protected] is insufficent.
This reiterates the need for a sound logical device naming scheme that
fits into driverfs without mucking up the basic structure. Not being a
expert on naming, the least offensive format I can think with regard to
iSCSI would be something along the lines of:
$DRIVERFS/virt/iscsi/iqn.2002-06.com.foo.super.turbo.disk.array.3543/disk0
being the iqn for an iSCSI Target node as viewed by an iSCSI Initiator
node.
Nicholas Bellinger
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
Roman Zippel wrote:
>
> Hi,
>
> On Sat, 22 Jun 2002, David Brownell wrote:
>
> > Why shouldn't there be a $DRIVERFS/net/[email protected]/... style hookup
> > for iSCSI devices? Using whatever physical addressing the kernel uses
> > there, which I assume wouldn't necessarily be restricted to ipv4.
>
> iSCSI devices are uniqely identified by its name. An iSCSI device can be
> reachable at multiple ip numbers or they can even change dynamically.
Roman,
Trying to clear up the nomenclature here, according to SAM-2
( http://www.10.org ) target ports have mandatory "identifiers"
and optional "names". The WWUI in iSCSI is part of the
target _identifier_. SAM-2 is pretty vague about "names"
but it does note that for a logical unit, its _name_
may be reported in the Device Identification VPD page in
an INQUIRY.
Doug Gilbert
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
Hi,
On Sat, 22 Jun 2002, Douglas Gilbert wrote:
> Trying to clear up the nomenclature here, according to SAM-2
> ( http://www.10.org ) target ports have mandatory "identifiers"
> and optional "names". The WWUI in iSCSI is part of the
> target _identifier_. SAM-2 is pretty vague about "names"
> but it does note that for a logical unit, its _name_
> may be reported in the Device Identification VPD page in
> an INQUIRY.
iSCSI currently specifies two types of names:
1. iSCSI Qualified Name: contains a date, domain and an arbitrary name,
e.g. "iqn.2001-04.com.acme.diskarrays-sn-a8675309"
2. IEEE EUI-64 format: an IEEE assigned name, e.g.
"eui.02004567A425678D"
bye, Roman
> This reiterates the need for a sound logical device naming scheme that
> fits into driverfs without mucking up the basic structure. Not being a
> expert on naming, the least offensive format I can think with regard to
> iSCSI would be something along the lines of:
>
> $DRIVERFS/virt/iscsi/iqn.2002-06.com.foo.super.turbo.disk.array.3543/disk0
That could do the job, but I'll leave those discussions up to SCSI
experts ... seems there are folk there who know something about the
topic, unlike me ! :)
Perhaps such things will be discussed at OLS next week, not that
I'll be there.
- Dave
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
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
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
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
> One thing that is very confusing about the current
> drivers/base code is that "struct bus' really has nothing to do
> with a bus. It should be called "struct device_type." For example,
> sd_mod (scsi disk), sr_mod (scsi cdrom), and sg (scsi generic) are
> all drivers for arbitrary scsi devices, regardless of whether
> they are connected by scsi ribbon cable, usb, or whatever.
I assume you're talking about 'struct bus_type'. They're there to
represent types of buses. There is one or each type of bus. There should
be one for SCSI, but it doesn't care about what the device type is.
'struct device_class', which is coming soon, is used to represent types of
devices, like disks, cdroms, etc. Device classes don't care what bus a
device resides on. It's the logical interface to the device.
-pat
On Sat, 22 Jun 2002, David Brownell wrote:
> > 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.
>
> There are those who see the IP stack as a kind of logical bus ... :)
> It's just not tied any specific hardware interface; it's "multipathed" in
> some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0
> would be wrong, since it can also be accessed through eth2.
It's not wrong, it's just makes life interesting when you want
accurately represent the presence of the device via both paths, or you
want to deal with the removal or power management of the bridge device.
That problem needs to be addressed; soon.
> Why shouldn't there be a $DRIVERFS/net/[email protected]/... style
> hookup for iSCSI devices? Using whatever physical addressing the
> kernel uses there, which I assume wouldn't necessarily be restricted
> to ipv4. (And not exposing physical network topology -- routing! --
> in driverfs.)
You can very well use driverfs to expose those attributes, and is one of
the things that we've been discussing at the kernel summit. driverfs will
take over the world. But, I still think the device is best represented as
a child of the phsysical network device.
> On a related topic ... if driverfs is going to be providing a nice unique
> ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for
> Linus' behind-two-bridges case), why are people talking as if the SCSI
> layer's arbitrary "controller number" should still be getting pushed as
> part of user visible names?
>
> That is, I'd sure hope the standard policy for assigning driverfs names
> would avoid _all_ IDs that are derived from enumeration order. Otherwise
> it'll be hard to store those names for (re)use by user mode tools.
The bus_id of the device is intended to represent the bus-specific ID of
the device, and is the name of the driverfs directory.
The name should user-friendly. It shouldn't be a unique name. Use
something nice and pretty. If people need/want a UUID, add it to the
bus-specific or type-specific structure, and export it via driverfs. It
will eventually make it to the generic structure.
-pat
> This reiterates the need for a sound logical device naming scheme that
> fits into driverfs without mucking up the basic structure. Not being a
> expert on naming, the least offensive format I can think with regard to
> iSCSI would be something along the lines of:
The device model will not give devices default names. It will pass the
responsibility to userspace, along with the path to the device via
/sbin/hotplug. From the patch, the userspace agent can derive various
things from the device's directory, including the device type and the UUID
of the device. From this, userspace can look up what to name the device.
-pat
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.."
>>Why shouldn't there be a $DRIVERFS/net/[email protected]/... style
>>hookup for iSCSI devices? Using whatever physical addressing the
>>kernel uses there, which I assume wouldn't necessarily be restricted
>>to ipv4. (And not exposing physical network topology -- routing! --
>>in driverfs.)
>
>
> You can very well use driverfs to expose those attributes, and is one of
> the things that we've been discussing at the kernel summit. driverfs will
> take over the world. But, I still think the device is best represented as
> a child of the phsysical network device.
Which one? I'd certainly hope that drivers wouldn't have to choose which
of the various network interfaces to register under, or register under
every network interface concurrently. (Or only the ones they might
conceivably be routed to go out on...) Given a bonded network link (going
out over multiple physical drivers) that'd get hairy. And what about
devices that host several logical interfaces? Or when the interfaces get
moved to some other device?
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
sensible in such cases. Which is not to say it's without additional issues
(like how to establish/maintain driver linkages that are DAGs not single
parent trees) but it wouldn't require drivers to dig as deeply into lower
levels of their stack. (And some network interfaces might well live in
such a non-physical tree, not just iSCSI...)
I think that problem wouldn't quite be isomorphic to multipath access to
devices, though it seems to be related. "Driver stacking" is an area
that "driverfs" doesn't seem to address quite yet ... not needed in the
simpler driver scenarios, so that's what I'd expect at this stage.
- Dave
> 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
> > 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
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
On Tue, 2002-06-25 at 11:49, David Brownell wrote:
> >>Why shouldn't there be a $DRIVERFS/net/[email protected]/... style
> >>hookup for iSCSI devices? Using whatever physical addressing the
> >>kernel uses there, which I assume wouldn't necessarily be restricted
> >>to ipv4. (And not exposing physical network topology -- routing! --
> >>in driverfs.)
> >
> >
> > You can very well use driverfs to expose those attributes, and is one of
> > the things that we've been discussing at the kernel summit. driverfs will
> > take over the world. But, I still think the device is best represented as
> > a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
I hate to kick the already deceased horse but..
This appears to be one of the larger problems that nobody (aside from
this thread :) seems to be raising. I understand Pat's logic of wanting
to keep the logical device a child of the network card, but in many
situations (espically the enterprise ones with regard multipathed IP
storage, along with David's examples above) I just dont see how that can
be done correctly in keeping all the prementioned virtual devices part
of the network device's directory in the tree.
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into lower
> levels of their stack. (And some network interfaces might well live in
> such a non-physical tree, not just iSCSI...)
>
I am in complete agreement, from my little view of where driverfs
currently stands a non-physical tree is going to have to happen sooner
or later, why not now?
> I think that problem wouldn't quite be isomorphic to multipath access to
> devices, though it seems to be related. "Driver stacking" is an area
> that "driverfs" doesn't seem to address quite yet ... not needed in the
> simpler driver scenarios, so that's what I'd expect at this stage.
>
> - Dave
>
Thanks!
Nicholas Bellinger
> 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
> > That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> > sensible in such cases. Which is not to say it's without additional issues
> > (like how to establish/maintain driver linkages that are DAGs not single
> > parent trees) but it wouldn't require drivers to dig as deeply into lower
> > levels of their stack. (And some network interfaces might well live in
> > such a non-physical tree, not just iSCSI...)
> >
>
> I am in complete agreement, from my little view of where driverfs
> currently stands a non-physical tree is going to have to happen sooner
> or later, why not now?
No. The physical hierarchy in driverfs is meant to be as accurate as
possible. Yes, it's idealistic, and at some point we might have to make a
bit of an exception. But, I refuse to break that model yet.
-pat
Hi!
> >>Why shouldn't there be a $DRIVERFS/net/[email protected]/... style
> >>hookup for iSCSI devices? Using whatever physical addressing the
> >>kernel uses there, which I assume wouldn't necessarily be restricted
> >>to ipv4. (And not exposing physical network topology -- routing! --
> >>in driverfs.)
> >
> >
> >You can very well use driverfs to expose those attributes, and is one of
> >the things that we've been discussing at the kernel summit. driverfs will
> >take over the world. But, I still think the device is best represented as
> >a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into
> >>lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason
why it could not exist with some kind of advanced fibrechannel.
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
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