public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* Re: /proc/scsi/map
@ 2002-06-18 15:40 Bryan Henderson
  2002-06-18 16:09 ` /proc/scsi/map Doug Ledford
  0 siblings, 1 reply; 33+ messages in thread
From: Bryan Henderson @ 2002-06-18 15:40 UTC (permalink / raw)
  To: Doug Ledford; +Cc: Kurt Garloff, Linux SCSI list


>There simply is *no* guarantee here of
>any consistent naming, so don't bother trying to claim there is.

That's quite an overstatement.  With a minor and reasonable qualification,
there is a guarantee.  That qualification is that you keep your controller
numbers the same.  On the myriad systems that have only one controller,
that is a very reasonable qualification indeed.

There are always qualifications when we say "guaranteed."  Here are some
others in this case that you didn't mention: you keep the device jumpers
the same, you keep the logical unit numbers the same (frequently not the
case with large storage subsystems), you keep your devices plugged into the
same place.

And that's without even getting into the higher issue of what does "the
same device" mean?




^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: /proc/scsi/map
@ 2002-06-17 22:06 Bryan Henderson
  0 siblings, 0 replies; 33+ messages in thread
From: Bryan Henderson @ 2002-06-17 22:06 UTC (permalink / raw)
  To: Kurt Garloff; +Cc: Linux SCSI list


>No. I was not wanting to give a numbering to SCSI devices. They don't
have.
>The high level driver attached to them however do. That's what is
reported.

Ah yes.  It's been a long time since I looked at how the SCSI drivers are
put together, and I remembered it wrong.

The basis for my discomfort was just what appeared in the example to be
special treatment of sg.  Patrick's comments more closely reflect what I
would have said if I knew what I was talking about.

What would the output look like in a system that has no sg driver?




^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: /proc/scsi/map
@ 2002-06-17 15:57 Bryan Henderson
  2002-06-17 20:28 ` /proc/scsi/map Kurt Garloff
  0 siblings, 1 reply; 33+ messages in thread
From: Bryan Henderson @ 2002-06-17 15:57 UTC (permalink / raw)
  To: Kurt Garloff; +Cc: Linux SCSI list


>Actually, the exact format of /proc/scsi/map is certainly something
>that can be discussed separately from the basic idea of adding a file
>that does expose the mapping of a SCSI address (CBTU) and the attached
>high level drivers.

Good.  Because there's one thing in the currently proposed format that is
wrong.  The "sg_num" column doesn't make sense -- it's a layering
violation.  The information in this column is meaningful independent of
whether the user uses  or the system has a Generic SCSI high level driver
(sg).  And the names here can be confused with device special file names
(/dev/sg5, etc) which of course the kernel knows nothing about.

The actual information given by this column is the Linux SCSI slot number
-- that elusive identifier that makes all this SCSI naming stuff hard in
the first place.  I suggest the column heading (if there is a header line
at all) be "slot" and the contents of the column be a simple decimal
number.

Users of the sg driver need to know separately that the device minor
number, and hence the N in /dev/sgN on a conventional system, is the Linux
SCSI slot number.




^ permalink raw reply	[flat|nested] 33+ messages in thread
* RE: /proc/scsi/map
@ 2002-06-17 12:55 Heinz, Michael
  0 siblings, 0 replies; 33+ messages in thread
From: Heinz, Michael @ 2002-06-17 12:55 UTC (permalink / raw)
  To: Sancho Dauskardt, Kurt Garloff, Linux kernel list,
	Linux SCSI list
  Cc: linux-usb-devel, linux1394-devel

>From an infiniband point of view, this sounds great!

--
Michael Heinz
Infinicon Systems, Inc.
http://www.infiniconsys.com 

> -----Original Message-----
> From: Sancho Dauskardt [mailto:sancho@dauskardt.de]
> Sent: Saturday, June 15, 2002 3:50 PM
> To: Kurt Garloff; Linux kernel list; Linux SCSI list
> Cc: linux-usb-devel@lists.sourceforge.net;
> linux1394-devel@lists.sourceforge.net
> Subject: Re: /proc/scsi/map
> 
> 
> 
> >Life would be easier if the scsi subsystem would just report 
> which SCSI
> >device (uniquely identified by the 
> controller,bus,target,unit tuple) belongs
> >to which high-level device. The information is available in 
> the kernel.
> >
> >Attached patch does this:
> >garloff@pckurt:/raid5/Kernel/src $ cat /proc/scsi/map
> ># C,B,T,U       Type    onl     sg_nm   sg_dev  nm      dev(hex)
> >0,0,00,00       0x05    1       sg0     c:15:00 sr0     b:0b:00
> [...]
> 
> Great, this was really missing badly.
> 
> But how about adding another column: GUID.
> Most usb-storage and (all?) FireWire devices have such a 
> unique identitiy.
> In contrast to native SCSI devices, these emulated SCSI devices on 
> hot-plugging busses will change their LUNs/IDs. Therefor the 
> GUID is really 
> a must to be able to create stable names (laptop suspend, etc.).
> 
> Both usb-storage and iee1394-sbp2 know the GUID. It only needs to be 
> communicated..
> 
> I'd guess that FibreChannel has similar problems ?
> 
> - sda
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 33+ messages in thread
[parent not found: <UTC200206151604.g5FG4JQ26968.aeb@smtp.cwi.nl>]
* Re: /proc/scsi/map
@ 2002-06-16  8:24 Andries.Brouwer
  0 siblings, 0 replies; 33+ messages in thread
From: Andries.Brouwer @ 2002-06-16  8:24 UTC (permalink / raw)
  To: dougg; +Cc: linux-scsi

>> Yes, but I'll wait for 2.5.22 so that it is clear against
>> what tree to diff.

> perhaps you could send your 2.5.21 patch to me

OK. A moment ago I constructed a patch against some random tree
and removed most unrelated stuff. See below.

Andries

diff -u -r linux-2.5.21y/linux/drivers/scsi/hosts.h linux-2.5.21az/linux/drivers/scsi/hosts.h
--- linux-2.5.21y/linux/drivers/scsi/hosts.h	Sun Jun  9 07:28:47 2002
+++ linux-2.5.21az/linux/drivers/scsi/hosts.h	Sat Jun 15 16:41:58 2002
@@ -516,6 +516,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 -u -r linux-2.5.21y/linux/drivers/scsi/osst.c linux-2.5.21az/linux/drivers/scsi/osst.c
--- linux-2.5.21y/linux/drivers/scsi/osst.c	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/osst.c	Sun Jun 16 10:13:43 2002
@@ -154,6 +154,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 =
 {
@@ -165,7 +166,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);
@@ -5416,6 +5418,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 -u -r linux-2.5.21y/linux/drivers/scsi/scsi.c linux-2.5.21az/linux/drivers/scsi/scsi.c
--- linux-2.5.21y/linux/drivers/scsi/scsi.c	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/scsi.c	Sat Jun 15 22:36:16 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
 
@@ -1542,6 +1543,73 @@
 }
 
 #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;
+	
+	size = sprintf(buffer + len, "# C,B,T,U\tType\tonl\tsg_nm\tsg_dev\tnm\tdev(hex)\n");
+	len += size;
+	pos = begin + len;
+
+	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;
@@ -1563,8 +1631,8 @@
 	pos = begin + len;
 	for (HBA_ptr = scsi_hostlist; HBA_ptr; HBA_ptr = HBA_ptr->next) {
 #if 0
-		size += sprintf(buffer + len, "scsi%2d: %s\n", (int) HBA_ptr->host_no,
-				HBA_ptr->hostt->procname);
+		size += sprintf(buffer + len, "scsi%2d: %s\n",
+			(int) HBA_ptr->host_no, HBA_ptr->hostt->procname);
 		len += size;
 		pos = begin + len;
 #endif
@@ -2502,6 +2570,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");
@@ -2538,6 +2607,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);
@@ -2573,6 +2649,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 -u -r linux-2.5.21y/linux/drivers/scsi/scsi.h linux-2.5.21az/linux/drivers/scsi/scsi.h
--- linux-2.5.21y/linux/drivers/scsi/scsi.h	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/scsi.h	Sat Jun 15 16:41:58 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 -u -r linux-2.5.21y/linux/drivers/scsi/scsi_proc.c linux-2.5.21az/linux/drivers/scsi/scsi_proc.c
--- linux-2.5.21y/linux/drivers/scsi/scsi_proc.c	Sun Jun  9 07:27:02 2002
+++ linux-2.5.21az/linux/drivers/scsi/scsi_proc.c	Sat Jun 15 22:49:21 2002
@@ -288,9 +288,10 @@
 
 	y += sprintf(buffer + len + y, "  Type:   %s ",
 		     scd->type < MAX_SCSI_DEVICE_CODE ?
-	       scsi_device_types[(int) scd->type] : "Unknown          ");
-	y += sprintf(buffer + len + y, "               ANSI"
-		     " SCSI revision: %02x", (scd->scsi_level - 1) ? scd->scsi_level - 1 : 1);
+		     scsi_device_types[(int) scd->type] : "Unknown          ");
+	y += sprintf(buffer + len + y,
+		     "               ANSI SCSI revision: %02x",
+		     (scd->scsi_level - 1) ? scd->scsi_level - 1 : 1);
 	if (scd->scsi_level == 2)
 		y += sprintf(buffer + len + y, " CCS\n");
 	else
@@ -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 -u -r linux-2.5.21y/linux/drivers/scsi/sd.c linux-2.5.21az/linux/drivers/scsi/sd.c
--- linux-2.5.21y/linux/drivers/scsi/sd.c	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/sd.c	Sat Jun 15 20:30:34 2002
@@ -102,6 +102,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,
@@ -121,6 +122,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);
@@ -284,6 +286,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)
@@ -1190,7 +1210,7 @@
 static int sd_registered;
 
 /**
- *	sd_init- called during driver initialization (after
+ *	sd_init - called during driver initialization (after
  *	sd_detect() is called for each scsi device present).
  *
  *	Returns 0 is successful (or already called); 1 if error
diff -u -r linux-2.5.21y/linux/drivers/scsi/sg.c linux-2.5.21az/linux/drivers/scsi/sg.c
--- linux-2.5.21y/linux/drivers/scsi/sg.c	Sun Jun  9 07:29:42 2002
+++ linux-2.5.21az/linux/drivers/scsi/sg.c	Sun Jun 16 10:18:05 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 -u -r linux-2.5.21y/linux/drivers/scsi/sr.c linux-2.5.21az/linux/drivers/scsi/sr.c
--- linux-2.5.21y/linux/drivers/scsi/sr.c	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/sr.c	Sat Jun 15 17:20:17 2002
@@ -69,6 +69,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,
@@ -82,7 +84,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;
@@ -469,6 +472,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 -u -r linux-2.5.21y/linux/drivers/scsi/st.c linux-2.5.21az/linux/drivers/scsi/st.c
--- linux-2.5.21y/linux/drivers/scsi/st.c	Sun Jun 16 10:05:40 2002
+++ linux-2.5.21az/linux/drivers/scsi/st.c	Sun Jun 16 10:13:14 2002
@@ -156,6 +156,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,
@@ -165,7 +166,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);
@@ -3910,6 +3912,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();

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: /proc/scsi/map
@ 2002-06-15 23:00 Andries.Brouwer
  0 siblings, 0 replies; 33+ messages in thread
From: Andries.Brouwer @ 2002-06-15 23:00 UTC (permalink / raw)
  To: Andries.Brouwer, dougg; +Cc: garloff, linux-kernel, linux-scsi

    From dougg@torque.net  Sat Jun 15 23:10:06 2002

    In the lsml "[RFC] Persistent naming of scsi devices" thread
    Martin K. Petersen <mkp@mkp.net> summarized scsi addressing issues
    thus:
    #
    # What we want is (at least) three ways of addressing a device:
    #
    # 1. By content.  This is the persistent naming.  Think
    #    filesystem/MD/LVM UUID.  This is what you put in /etc/fstab and
    #    what metadisk systems use to assemble logical volumes.
    #
    #    Content referencing is used for accessing data.
    #
    # 2. By physical path.  This naming is not persistent.  Not even runtime
    #    because hotplug, iSCSI and whatnot may mess things up.
    #
    #    Path naming is for discovery and recovery.  When you add an
    #    unlabeled disk you want to reference it by path to give it a name.
    #    When you have a failed disk on your system you want to know which
    #    physical device to pull from the array.
    #
    # 3. By enumeration.  This is what the kernel happens to be using to
    #    reference the device.  diskN.  Certainly not persistent.
    #
    #    Enumeration is for the kernel.

Yes, a very nice summary. Maybe also

# 4. By fingerprint.  This naming is persistent, but need not
#    identify the device uniquely.  Think device type, vendor,
#    serial number, capacity.
#
#    Fingerprints are convenient for the user. "My ZIP drive".


    The /proc/scsi/map facility proposed by Kurt does a very
    good job at tying together points 2) and 3) .

Yes. Or, more precisely, it ties together the name sde and the
path (C,B,T,U) = (3,0,00,01). However, this path is not very
"physical". Indeed, these four numbers all arose by enumeration -
they are kernel numbers for some usb-storage device.

I can find the physical path, but that requires quite some digging in
/proc/scsi/scsi and /proc/scsi/sg/host_strs and /proc/scsi/usb-storage*/*
and /proc/bus/usb/devices.


    > Very good - in combination with /proc/scsi/scsi this gives
    > good information. I like it.

    Adding INQUIRY strings would make it harder to parse and more
    cluttered for humans to read.

Yes, I would like to leave that to a user-space utility.
Writing that will also show what kernel facilities are missing.

    > But just "cat /proc/scsi/map" is not good enough.
    > From the above output alone one cannot easily guess which is which.
    > One would need a small utility that reads /proc/scsi/map and
    > /proc/scsi/scsi and produces something readable.

    Note the possible race condition: reading /proc/scsi/scsi
    then /proc/scsi/map (or vice versa) when a hotplug is
    occurring...

Already reading /proc/scsi/map has a race: no locking is done.

    > Will add sth to util-linux in case this gets accepted.

    IMO as soon as lk 2.4.19 comes out, this patch should
    be presented to Marcelo (for inclusion in lk 2.4.20).

Yes, perhaps. I would like to get some experience first,
play with it, see what information is missing.

I have to admit that 2.5 is not very suitable for development
these days, it is not stable enough, but the appropriate path
is to try things out in 2.5 first, and when something crystallizes
out, backport.

    The sooner we get it into the lk 2.5 series the better. Could you 
    forward your lk 2.5 version of Kurt's patch to Linus (and the
    linux-scsi list)?

Yes, but I'll wait for 2.5.22 so that it is clear against
what tree to diff.

Andries

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: /proc/scsi/map
@ 2002-06-15 21:54 Andries.Brouwer
  0 siblings, 0 replies; 33+ messages in thread
From: Andries.Brouwer @ 2002-06-15 21:54 UTC (permalink / raw)
  To: garloff, linux-kernel, linux-scsi, sancho
  Cc: linux-usb-devel, linux1394-devel

    >Life would be easier if the scsi subsystem would just report which SCSI
    >device (uniquely identified by the controller,bus,target,unit tuple) belongs
    >to which high-level device. The information is available in the kernel.
    >
    >Attached patch does this:
    >garloff@pckurt:/raid5/Kernel/src $ cat /proc/scsi/map
    ># C,B,T,U       Type    onl     sg_nm   sg_dev  nm      dev(hex)
    >0,0,00,00       0x05    1       sg0     c:15:00 sr0     b:0b:00
    [...]

    Great, this was really missing badly.

    But how about adding another column: GUID.
    Most usb-storage and (all?) FireWire devices have such a unique identitiy.
    In contrast to native SCSI devices, these emulated SCSI devices on 
    hot-plugging busses will change their LUNs/IDs. Therefor the GUID is
    really a must to be able to create stable names (laptop suspend, etc.).

    Both usb-storage and iee1394-sbp2 know the GUID. It only needs to be 
    communicated..

The usb-storage GUID is just one random item of information.
One might wish for much more.

And: this information is already somewhere:

% cat /proc/scsi/sg/host_strs
SCSI host adapter emulation for IDE ATAPI devices
Iomega VPI2 (imm) interface
SCSI emulation for USB Mass Storage devices
SCSI emulation for USB Mass Storage devices
%

This tells me that host 0 will be in ide-scsi, host 1 in imm,
host 2 in usb-storage-0, host 3 in usb-storage-1.
And

% cat /proc/scsi/ide-scsi/0
SCSI host adapter emulation for IDE ATAPI devices
% cat /proc/scsi/imm/1
Version : 2.05 (for Linux 2.4.0)
Parport : parport0
Mode    : SPP
% cat /proc/scsi/usb-storage-0/2
   Host scsi2: usb-storage
       Vendor: DataFab Systems Inc.
      Product: USB CF+SM
Serial Number: 5DC69477C6
     Protocol: Transparent SCSI
    Transport: Datafab Bulk-Only
         GUID: 07c4a1090000005dc69477c6
     Attached: Yes
% cat /proc/scsi/usb-storage-1/3
   Host scsi3: usb-storage
       Vendor: SCM Microsystems Inc.
      Product: eUSB SmartMedia / CompactFlash 
Serial Number: None
     Protocol: Transparent SCSI
    Transport: Control/Bulk-EUSB/SDDR09
         GUID: 04e600050000000000000000
     Attached: Yes
%

A small utility that looks around in /proc is able to
find the GUID. Of course it would be better when fewer
heuristics were required.

Finally, the GUIDs you see here do not determine the LUN.
So, there is no well-defined line in /proc/scsi/map
where they would belong.

Andries

^ permalink raw reply	[flat|nested] 33+ messages in thread
* Re: /proc/scsi/map
@ 2002-06-15 21:08 Douglas Gilbert
  0 siblings, 0 replies; 33+ messages in thread
From: Douglas Gilbert @ 2002-06-15 21:08 UTC (permalink / raw)
  To: Andries.Brouwer; +Cc: linux-scsi, linux-kernel, Kurt Garloff

Andries.Brouwer@cwi.nl wrote:

> > How can one assign stable device names to SCSI devices in
> > case there are devices that may or may not be switched on or connected.
> 
> An interesting unsolved problem.
> [Your discussion confuses a few things, especially in the context
> of removable devices: a uuid lives on the disk, the C,B,T,U tends
> to identify the drive rather than the disk.]

In the lsml "[RFC] Persistent naming of scsi devices" thread
Martin K. Petersen <mkp@mkp.net> summarized scsi addressing issues
thus:
#
# What we want is (at least) three ways of addressing a device:
#
# 1. By content.  This is the persistent naming.  Think
#    filesystem/MD/LVM UUID.  This is what you put in /etc/fstab and
#    what metadisk systems use to assemble logical volumes.
#
#    Content referencing is used for accessing data.
#
# 2. By physical path.  This naming is not persistent.  Not even runtime
#    because hotplug, iSCSI and whatnot may mess things up.
#
#    Path naming is for discovery and recovery.  When you add an
#    unlabeled disk you want to reference it by path to give it a name.
#    When you have a failed disk on your system you want to know which
#    physical device to pull from the array.
#
# 3. By enumeration.  This is what the kernel happens to be using to
#    reference the device.  diskN.  Certainly not persistent.
#
#    Enumeration is for the kernel.

The /proc/scsi/map facility proposed by Kurt does a very
good job at tying together points 2) and 3) . As a bonus
it also shows the sg device to primary device mapping
(which is a major headache for me as the sg maintainer).

As for the physical path getting fooled by a re-plug, I would 
like to present the idea of a "device attach event number" 
which would be uniquely issued (ascending order) to each newly 
attached scsi device [an attach timestamp could be useful as well].
This is easy to implement, has a many-to-one
relationship with the physical path (i.e. C,B,T,U) but, at
any instant, has a one-to-one relationship. So the attach
event number can be used as an alias for C,B,T,U** and makes
no pretensions to be persistent from one kernel lifetime
to the next (on the same machine). The scsimon driver supports
a device "attach event number". If the idea is workable the
number should probably be put in the scsi mid-level (i.e.
Scsi_Device structure).

** The C,B,T,U tuple (or nexus) is already a handful and
will probably get uglier with 8-byte luns and iSCSI extensions.
The SCSI_IOCTL_GET_IDLUN tries to pack C,B,T,U into one integer
and obviously won't scale to an 8 byte lun. A new ioctl such as
SCSI_IOCTL_GET_PHYSICAL_PATH (for example) could fix "GET_IDLUN"'s
shortcomings and yield the device attach event number. 


Mike Sullivan (who started the above-mentioned "[RFC] Persistent 
naming of scsi devices" thread) recently presented patches on
lsml for a devnaming (and scsiname) utility. These patches  
address Martin's point 1) [content addressing].


There remains the issue of removable media (i.e. device stays
put but the media is changed). In the absence of asynchronous
event notification, the next (normal) scsi command receives a
"unit attention" to alert the kernel. I'm not sure if Mike's
patch addresses this issue.

> > Life would be easier if the scsi subsystem would just report which
> > SCSI device (uniquely identified by the controller,bus,target,unit tuple)
> > belongs to which high-level device.
> 
> Yes. I took your patch, ported it to 2.5, and tried it out.
> 
> # cat /proc/scsi/map
> # C,B,T,U       Type    onl     sg_nm   sg_dev  nm      dev(hex)
> 1,0,06,00       0x00    1       sg0     c:15:00 sda     b:08:00
> 2,0,00,00       0x00    1       sg1     c:15:01 sdb     b:08:10
> 2,0,00,01       0x00    1       sg2     c:15:02 sdc     b:08:20
> 3,0,00,00       0x00    1       sg3     c:15:03 sdd     b:08:30
> 3,0,00,01       0x00    1       sg4     c:15:04 sde     b:08:40
> 
> Very good - in combination with /proc/scsi/scsi this gives
> good information. I like it.

Adding INQUIRY strings would make it harder to parse and more
cluttered for humans to read.

> But just "cat /proc/scsi/map" is not good enough.
> From the above output alone one cannot easily guess which is which.
> One would need a small utility that reads /proc/scsi/map and
> /proc/scsi/scsi and produces something readable.

Note the possible race condition: reading /proc/scsi/scsi
then /proc/scsi/map (or vice versa) when a hotplug is
occurring...

BTW In lk 2.5 we store the whole INQUIRY response in the
Scsi_Device structure. Currently we have no ioctl to yield
this information to the user space :-(

> Will add sth to util-linux in case this gets accepted.

IMO as soon as lk 2.4.19 comes out, this patch should
be presented to Marcelo (for inclusion in lk 2.4.20). The 
sooner we get it into the lk 2.5 series the better. Could you 
forward your lk 2.5 version of Kurt's patch to Linus (and the
linux-scsi list)?

Doug Gilbert

^ permalink raw reply	[flat|nested] 33+ messages in thread
[parent not found: <garloff@suse.de>]
end of thread, other threads:[~2002-06-18 16:09 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <UTC200206152154.g5FLsCI23053.aeb@smtp.cwi.nl>
2002-06-15 22:27 ` /proc/scsi/map Douglas Gilbert
2002-06-15 22:40   ` /proc/scsi/map Sancho Dauskardt
2002-06-16 20:36     ` /proc/scsi/map Kurt Garloff
2002-06-15 22:28 ` /proc/scsi/map Sancho Dauskardt
2002-06-16 17:05 ` [linux-usb-devel] /proc/scsi/map David Brownell
2002-06-18 15:40 /proc/scsi/map Bryan Henderson
2002-06-18 16:09 ` /proc/scsi/map Doug Ledford
  -- strict thread matches above, loose matches on Subject: below --
2002-06-17 22:06 /proc/scsi/map Bryan Henderson
2002-06-17 15:57 /proc/scsi/map Bryan Henderson
2002-06-17 20:28 ` /proc/scsi/map Kurt Garloff
2002-06-17 12:55 /proc/scsi/map Heinz, Michael
     [not found] <UTC200206151604.g5FG4JQ26968.aeb@smtp.cwi.nl>
2002-06-16 21:04 ` /proc/scsi/map Kurt Garloff
2002-06-16  8:24 /proc/scsi/map Andries.Brouwer
2002-06-15 23:00 /proc/scsi/map Andries.Brouwer
2002-06-15 21:54 /proc/scsi/map Andries.Brouwer
2002-06-15 21:08 /proc/scsi/map Douglas Gilbert
     [not found] <garloff@suse.de>
2002-06-15 13:36 ` /proc/scsi/map Kurt Garloff
2002-06-15 14:08   ` /proc/scsi/map John Summerfield
2002-06-17 11:33     ` /proc/scsi/map Kurt Garloff
2002-06-15 15:52   ` /proc/scsi/map Richard Gooch
2002-06-16 19:41     ` /proc/scsi/map Kurt Garloff
2002-06-15 19:49   ` /proc/scsi/map Sancho Dauskardt
2002-06-16 19:24   ` /proc/scsi/map Albert D. Cahalan
2002-06-16 21:22     ` /proc/scsi/map Kurt Garloff
2002-06-17 20:35   ` /proc/scsi/map Patrick Mansfield
2002-06-17 20:57     ` /proc/scsi/map Kurt Garloff
2002-06-17 21:47       ` /proc/scsi/map Patrick Mansfield
2002-06-17 22:08   ` /proc/scsi/map Doug Ledford
2002-06-17 23:06     ` /proc/scsi/map Kurt Garloff
     [not found]     ` <20020617230648.GA3448@gum01m.etpnet.phys.tue.nl>
2002-06-18  2:40       ` /proc/scsi/map Doug Ledford
2002-06-18  4:32         ` /proc/scsi/map Douglas Gilbert
2002-06-18  5:12           ` /proc/scsi/map Doug Ledford
2002-06-18  9:03         ` /proc/scsi/map Kurt Garloff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox