[PATCH] Move SG_GET_SCSI_ID from sg to scsi

[PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Bodo Eggert]

Having a SCSI ID is a generic SCSI property, therefore reading it should 
not be restricted to sg. The SCSI_IOCTL_GET_IDLUN from scsi is limited 
below the kernel data types, so it isn't an adequate replacement.

This patch moves SG_GET_SCSI_ID from sg to scsi while renaming it to
SCSI_IOCTL_GET_PCI. Additionally, I renamed struct sg_scsi_id to struct
scsi_ioctl_id, since it is no longer restricted to sg. The corresponding 
typedef will be gone.

Signed-off-by: Bodo Eggert <7eggert@gmx.de>

---
This patch applies to 2.6.16. No structural change is made to the struct 
nor the IOCTL number, so userspace will continue to work properly.

Maybe this IOCTL should be extended to return the 64 bit LUN, but I wasn't
able to find out enough details to do the change within reasonable time.

diff -pruN -X dontdiff 2.6.15.ori/drivers/scsi/scsi_ioctl.c 2.6.15/drivers/scsi/scsi_ioctl.c
--- 2.6.15.ori/drivers/scsi/scsi_ioctl.c	2006-02-08 15:10:48.000000000 +0100
+++ 2.6.15/drivers/scsi/scsi_ioctl.c	2006-03-26 20:24:24.000000000 +0200
@@ -434,6 +434,27 @@ int scsi_ioctl(struct scsi_device *sdev,
 				     START_STOP_TIMEOUT, NORMAL_RETRIES);
         case SCSI_IOCTL_GET_PCI:
                 return scsi_ioctl_get_pci(sdev, arg);
+	case SG_GET_SCSI_ID:
+		if (!access_ok(VERIFY_WRITE, arg, sizeof (struct scsi_ioctl_id)))
+			return -EFAULT;
+		else {
+			struct scsi_ioctl_id __user *idp = arg;
+
+			__put_user((int) sdev->host->host_no,
+				   &idp->host_no);
+			__put_user((int) sdev->channel,
+				   &idp->channel);
+			__put_user((int) sdev->id, &idp->scsi_id);
+			__put_user((int) sdev->lun, &idp->lun);
+			__put_user((int) sdev->type, &idp->scsi_type);
+			__put_user((short) sdev->host->cmd_per_lun,
+				   &idp->h_cmd_per_lun);
+			__put_user((short) sdev->queue_depth,
+				   &idp->d_queue_depth);
+			__put_user(0, &idp->unused[0]);
+			__put_user(0, &idp->unused[1]);
+			return 0;
+		}
 	default:
 		if (sdev->host->hostt->ioctl)
 			return sdev->host->hostt->ioctl(sdev, cmd, arg);
diff -pruN -X dontdiff 2.6.15.ori/drivers/scsi/sg.c 2.6.15/drivers/scsi/sg.c
--- 2.6.15.ori/drivers/scsi/sg.c	2006-02-08 15:10:48.000000000 +0100
+++ 2.6.15/drivers/scsi/sg.c	2006-03-11 11:20:16.000000000 +0100
@@ -871,29 +871,6 @@ sg_ioctl(struct inode *inode, struct fil
 		return 0;
 	case SG_GET_LOW_DMA:
 		return put_user((int) sfp->low_dma, ip);
-	case SG_GET_SCSI_ID:
-		if (!access_ok(VERIFY_WRITE, p, sizeof (sg_scsi_id_t)))
-			return -EFAULT;
-		else {
-			sg_scsi_id_t __user *sg_idp = p;
-
-			if (sdp->detached)
-				return -ENODEV;
-			__put_user((int) sdp->device->host->host_no,
-				   &sg_idp->host_no);
-			__put_user((int) sdp->device->channel,
-				   &sg_idp->channel);
-			__put_user((int) sdp->device->id, &sg_idp->scsi_id);
-			__put_user((int) sdp->device->lun, &sg_idp->lun);
-			__put_user((int) sdp->device->type, &sg_idp->scsi_type);
-			__put_user((short) sdp->device->host->cmd_per_lun,
-				   &sg_idp->h_cmd_per_lun);
-			__put_user((short) sdp->device->queue_depth,
-				   &sg_idp->d_queue_depth);
-			__put_user(0, &sg_idp->unused[0]);
-			__put_user(0, &sg_idp->unused[1]);
-			return 0;
-		}
 	case SG_SET_FORCE_PACK_ID:
 		result = get_user(val, ip);
 		if (result)
@@ -1071,6 +1048,7 @@ sg_ioctl(struct inode *inode, struct fil
 	case SCSI_IOCTL_GET_IDLUN:
 	case SCSI_IOCTL_GET_BUS_NUMBER:
 	case SCSI_IOCTL_PROBE_HOST:
+	case SCSI_IOCTL_GET_ID:
 	case SG_GET_TRANSFORM:
 		if (sdp->detached)
 			return -ENODEV;
diff -pruN -X dontdiff 2.6.15.ori/include/scsi/scsi.h 2.6.15/include/scsi/scsi.h
--- 2.6.15.ori/include/scsi/scsi.h	2006-02-08 15:11:08.000000000 +0100
+++ 2.6.15/include/scsi/scsi.h	2006-03-26 20:36:54.000000000 +0200
@@ -245,6 +245,17 @@ struct scsi_lun {
 	__u8 scsi_lun[8];
 };
 
+struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
+    int host_no;        /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */
+    int channel;
+    int scsi_id;        /* scsi id of target device */
+    int lun;
+    int scsi_type;      /* TYPE_... defined in scsi/scsi.h */
+    short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
+    short d_queue_depth;/* device (or adapter) maximum queue length */
+    int unused[2];      /* unused part should be zero */
+}; /* 32 bytes long on i386 */
+
 /*
  *  MESSAGE CODES
  */
@@ -427,4 +438,11 @@ struct scsi_lun {
 /* Used to obtain the PCI location of a device */
 #define SCSI_IOCTL_GET_PCI		0x5387
 
+/* The following ioctl has a 'struct scsi_ioctl_id *' object as its 3rd argument. */
+/* 'struct scsi_ioctl_id' was renamed from 'sg_scsi_id_t'. */
+#define SCSI_IOCTL_GET_ID 0x2276   /* Yields fd's bus, chan, dev, lun + type */
+#define SG_GET_SCSI_ID SCSI_IOCTL_GET_ID /* old name */
+/* SCSI id information can also be obtained from SCSI_IOCTL_GET_IDLUN, *
+ * but that is limited in range (/usurally/ no problem ...)            */
+
 #endif /* _SCSI_SCSI_H */
diff -pruN -X dontdiff 2.6.15.ori/include/scsi/sg.h 2.6.15/include/scsi/sg.h
--- 2.6.15.ori/include/scsi/sg.h	2005-06-17 21:48:29.000000000 +0200
+++ 2.6.15/include/scsi/sg.h	2006-03-11 12:10:14.000000000 +0100
@@ -155,18 +155,6 @@ typedef struct sg_io_hdr
 #define SG_INFO_DIRECT_IO 0x2   /* direct IO requested and performed */
 #define SG_INFO_MIXED_IO 0x4    /* part direct, part indirect IO */
 
-
-typedef struct sg_scsi_id { /* used by SG_GET_SCSI_ID ioctl() */
-    int host_no;        /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */
-    int channel;
-    int scsi_id;        /* scsi id of target device */
-    int lun;
-    int scsi_type;      /* TYPE_... defined in scsi/scsi.h */
-    short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
-    short d_queue_depth;/* device (or adapter) maximum queue length */
-    int unused[2];      /* probably find a good use, set 0 for now */
-} sg_scsi_id_t; /* 32 bytes long on i386 */
-
 typedef struct sg_req_info { /* used by SG_GET_REQUEST_TABLE ioctl() */
     char req_state;     /* 0 -> not used, 1 -> written, 2 -> ready to read */
     char orphan;        /* 0 -> normal request, 1 -> from interruped SG_IO */
@@ -195,10 +183,6 @@ typedef struct sg_req_info { /* used by 
 #define SG_SET_RESERVED_SIZE 0x2275  /* request a new reserved buffer size */
 #define SG_GET_RESERVED_SIZE 0x2272  /* actual size of reserved buffer */
 
-/* The following ioctl has a 'sg_scsi_id_t *' object as its 3rd argument. */
-#define SG_GET_SCSI_ID 0x2276   /* Yields fd's bus, chan, dev, lun + type */
-/* SCSI id information can also be obtained from SCSI_IOCTL_GET_IDLUN */
-
 /* Override host setting and always DMA using low memory ( <16MB on i386) */
 #define SG_SET_FORCE_LOW_DMA 0x2279  /* 0-> use adapter setting, 1-> force */
 #define SG_GET_LOW_DMA 0x227a   /* 0-> use all ram for dma; 1-> low dma ram */

-- 
as appealing as it might seem, it is impossible to patch or upgrade users
	-- Security Warrior

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Arjan van de Ven]

On Sun, 2006-03-26 at 21:28 +0200, Bodo Eggert wrote:
> Having a SCSI ID is a generic SCSI property, therefore reading it should 
> not be restricted to sg. The SCSI_IOCTL_GET_IDLUN from scsi is limited 
> below the kernel data types, so it isn't an adequate replacement.
> 
> This patch moves SG_GET_SCSI_ID from sg to scsi while renaming it to
> SCSI_IOCTL_GET_PCI. Additionally, I renamed struct sg_scsi_id to struct
> scsi_ioctl_id, since it is no longer restricted to sg. The corresponding 
> typedef will be gone.


To be honest, I think this is the wrong direction; this ioctl seems to
be a bad idea (it exposes the SPI parameters... while SPI is only one of
many nowadays). Expanding the use of such a thing... please no.

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Matthew Wilcox]

On Sun, Mar 26, 2006 at 09:51:38PM +0200, Arjan van de Ven wrote:
> On Sun, 2006-03-26 at 21:28 +0200, Bodo Eggert wrote:
> > Having a SCSI ID is a generic SCSI property, therefore reading it should 
> > not be restricted to sg. The SCSI_IOCTL_GET_IDLUN from scsi is limited 
> > below the kernel data types, so it isn't an adequate replacement.
> > 
> > This patch moves SG_GET_SCSI_ID from sg to scsi while renaming it to
> > SCSI_IOCTL_GET_PCI. Additionally, I renamed struct sg_scsi_id to struct
> > scsi_ioctl_id, since it is no longer restricted to sg. The corresponding 
> > typedef will be gone.
> 
> To be honest, I think this is the wrong direction; this ioctl seems to
> be a bad idea (it exposes the SPI parameters... while SPI is only one of
> many nowadays). Expanding the use of such a thing... please no.

What's SPI specific?

+struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
+    int host_no;        /* as in "scsi<n>" where 'n' is one of 0, 1, 2
etc */
+    int channel;
+    int scsi_id;        /* scsi id of target device */
+    int lun;
+    int scsi_type;      /* TYPE_... defined in scsi/scsi.h */
+    short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
+    short d_queue_depth;/* device (or adapter) maximum queue length */
+    int unused[2];      /* unused part should be zero */
+}; /* 32 bytes long on i386 */

Everything has to support HCIL, even if it's through some kind of
mapping.  Yes, I know it might not make much *sense* for some
transports, but we do need to support it.  Type isn't SPI-specific.
cmd_per_lun isn't SPI-specific either, and neither is d_queue_depth,
although neither may make too much sense for some adapters or targets.

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Arjan van de Ven]

> Everything has to support HCIL, even if it's through some kind of
> mapping. 

for now ;)
>  Yes, I know it might not make much *sense* for some
> transports, but we do need to support it.  

but at least we should support 64 bit luns etc then...
(there is padding space.. so it can even be done in the same struct)

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Matthew Wilcox]

On Sun, Mar 26, 2006 at 09:28:28PM +0200, Bodo Eggert wrote:
>          case SCSI_IOCTL_GET_PCI:
>                  return scsi_ioctl_get_pci(sdev, arg);
> +	case SG_GET_SCSI_ID:

You're using the old ioctl name here ...

> +		if (!access_ok(VERIFY_WRITE, arg, sizeof (struct scsi_ioctl_id)))
> +			return -EFAULT;
> +		else {
> +			struct scsi_ioctl_id __user *idp = arg;
> +
> +			__put_user((int) sdev->host->host_no,
> +				   &idp->host_no);

The cast isn't necessary; __put_user casts the argument to the type of
the pointer.

> +			__put_user(0, &idp->unused[0]);
> +			__put_user(0, &idp->unused[1]);

Is it time to repurpose the unused bytes for the 64-bit LUN?

> +struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
> +    int host_no;        /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */

tabs instead of spaces?

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Bodo Eggert]

On Sun, 26 Mar 2006, Matthew Wilcox wrote:

> On Sun, Mar 26, 2006 at 09:28:28PM +0200, Bodo Eggert wrote:
> >          case SCSI_IOCTL_GET_PCI:
> >                  return scsi_ioctl_get_pci(sdev, arg);
> > +	case SG_GET_SCSI_ID:
> 
> You're using the old ioctl name here ...

Bad, bad, bad ...

> > +		if (!access_ok(VERIFY_WRITE, arg, sizeof (struct scsi_ioctl_id)))
> > +			return -EFAULT;
> > +		else {
> > +			struct scsi_ioctl_id __user *idp = arg;
> > +
> > +			__put_user((int) sdev->host->host_no,
> > +				   &idp->host_no);
> 
> The cast isn't necessary; __put_user casts the argument to the type of
> the pointer.

Nice.

> > +			__put_user(0, &idp->unused[0]);
> > +			__put_user(0, &idp->unused[1]);
> 
> Is it time to repurpose the unused bytes for the 64-bit LUN?

ACK, but I didn't find out how to fill it, and having ints instead of
__uXX made the struct look ugly. Therefore I postponed it to a later patch.

> > +struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
> > +    int host_no;        /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */
> 
> tabs instead of spaces?

Will look at it.
-- 
 In:  DATA
 Out: 554 Error: no valid recipients
 In:  Received: from unknown (190.106.166.70)       -- SMTP-Dialog,
 Out: 221 Error: I can break rules, too. Goodbye.      found in d.a.n.m

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Matthew Wilcox]

On Mon, Mar 27, 2006 at 12:11:14PM +0200, Bodo Eggert wrote:
> > > +			__put_user(0, &idp->unused[0]);
> > > +			__put_user(0, &idp->unused[1]);
> > 
> > Is it time to repurpose the unused bytes for the 64-bit LUN?
> 
> ACK, but I didn't find out how to fill it, and having ints instead of
> __uXX made the struct look ugly. Therefore I postponed it to a later patch.

So we don't currently save the scsi_lun anywhere.  We, er, translate it
into a 32-bit int, and carry that around.  Obviously this is going to
have to change for things like iSCSI, but this is totally offtopic for
your patch.  So I agree with you, whoever adds the 64-bit LUN support
gets to patch the ioctl struct too.

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[James Bottomley]

On Mon, 2006-03-27 at 08:20 -0700, Matthew Wilcox wrote:
> So we don't currently save the scsi_lun anywhere.  We, er, translate it
> into a 32-bit int, and carry that around.  Obviously this is going to
> have to change for things like iSCSI, but this is totally offtopic for
> your patch.  So I agree with you, whoever adds the 64-bit LUN support
> gets to patch the ioctl struct too.

Actually, this is precisely the argument for why we don't want such an
ioctl at all.  This area is one of the ones there should be significant
changes in for the forseeable future.  32->64 bit LUNs are probably only
the start; then there'll be elimination of the target ID (or replacing
it with a string).  If we have this ioctl, every time this area changes,
so now does the user ABI.

Finally, I really don't think we want to encourage anybody in userspace
to rely on a string of internally generated numbers ... that's what
sysfs paths are for, but at least they're simply strings opaque, so we
can change them.

James

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Linus Torvalds]

On Sun, 26 Mar 2006, Bodo Eggert wrote:
>
> Having a SCSI ID is a generic SCSI property

No it's not.

Havign a SCSI ID is a f*cking idiotic thing to do.

Only idiots like Joerg Schilling thinks that any such thing even _exists_. 
It does not, never has, and never will.

The way you reach a SCSI device is through the device filename, and trying 
to use controller/channel/id/lun naming IS INSANE!

Stop it now. We should kill that ioctl, not try to make it look like it is 
sensible. It's not a sensible way to look up SCSI devices, and the fact 
that some SCSI people think it is is doesn't make it so.

The fact is, you CANNOT ID a SCSI device that way. Look at how /sys does 
it, and realize that there's a damn good reason we do it that way. We ID 
the same device in many different ways, because different people want to 
ID it differently.

You can ask "what's the first device we enumerated", you can ask "what's 
the physical path to the device" or you can ask "what's the intrisic UUID 
of the device". But the controller/channel/id/lun thing is just stupid. 
You can look it up that way if you want to, but I refuse to have idiotic 
interfaces that somehow try to make that the "official" name, when it 
clearly is NOT.

		Linus

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Jan Engelhardt]

>> Having a SCSI ID is a generic SCSI property
>
>No it's not.
>Havign a SCSI ID is a f*cking idiotic thing to do.
>
>Only [...] think that any such thing even _exists_. 
>It [...] never has, and never will.

Ah. So all the minix, bsd and sun c?t?[dps]? naming is based on what then 
(someone drinking just too much coffe?), if BTL/CTD/HCIL (call it what you 
want) never existed?


Jan Engelhardt
-- 

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Linus Torvalds]

On Mon, 27 Mar 2006, Jan Engelhardt wrote:
> 
> Ah. So all the minix, bsd and sun c?t?[dps]? naming is based on what then 
> (someone drinking just too much coffe?), if BTL/CTD/HCIL (call it what you 
> want) never existed?

Right. 

It was a stupid idea even in the 80's. It's only gotten stupider since.

Now, during the 80's it was at least _excusable_. It was reasonable to 
think that you can just enumerate the controllers. And it was simple, and 
since hotplug controllers back then was "operator plug", not the modern 
kind of "they magically show up", it worked and controller numbers _meant_ 
something (even though they'd change when you switched things around, but 
you can expect that).

These days, you just cannot enumerate controllers in any meaningful 
manner. I don't think you ever really could, but at least with static 
hardware, any random enumeration was as good as any other.

			Linus

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Bodo Eggert]

On Sun, 26 Mar 2006, Linus Torvalds wrote:
> On Sun, 26 Mar 2006, Bodo Eggert wrote:

> > Having a SCSI ID is a generic SCSI property
> 
> No it's not.

With respect to sg vs. scsi, it is.

> Havign a SCSI ID is a f*cking idiotic thing to do.
> 
> Only idiots like Joerg Schilling thinks that any such thing even _exists_. 
> It does not, never has, and never will.

For the host ID ACK, but some transports do support channel/ID/LUN. In
/these/ cases having them exported is a sane thing to do. I don't even try
to argue if it's better to use sysfs or ioctl.

> The way you reach a SCSI device is through the device filename, and trying 
> to use controller/channel/id/lun naming IS INSANE!

ACK, and having an address space of 340 * 10^36 will make it perfectly
clear. One day a subsystem might hand out ID and LUN cookies instead of
counters, and a certain table of sg numbers will stop fitting in memory.
I'm just handing out the bigger gun with the automatic foot-finder.-)

</chasing the pink herring>

> Stop it now. We should kill that ioctl, not try to make it look like it is 
> sensible. It's not a sensible way to look up SCSI devices, and the fact 
> that some SCSI people think it is is doesn't make it so.

Schedule for removal?

As I understand, having a /dev/sd0815 corresponding to a /dev/sg4711 is
the root of all evil and idiotic things, and moving all sg functions into
the apropiate place is the sane thing to do.

This patch is a part of the process, and as soon as all sg functions are
available using /dev/s[dtr]*, the corresponding sg devices should be
deprecated and removed.

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one.
	-- T. Jefferson

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Matthias Andree]

Bodo Eggert schrieb am 2006-03-27:

> As I understand, having a /dev/sd0815 corresponding to a /dev/sg4711 is
> the root of all evil and idiotic things, and moving all sg functions into
> the apropiate place is the sane thing to do.
> 
> This patch is a part of the process, and as soon as all sg functions are
> available using /dev/s[dtr]*, the corresponding sg devices should be
> deprecated and removed.

Oh, I hear Schilling wailing...

Seriously, at the time such changes are committed, a good manual for how
user-space applications are to be upgraded wouldn't hurt, and I am
indeed proposing that those familiar with the code should write it -
perhaps when porting an existing application to the new interfaces.

-- 
Matthias Andree

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Douglas Gilbert]

Linus Torvalds wrote:
> 
> On Sun, 26 Mar 2006, Bodo Eggert wrote:
> 
>>Having a SCSI ID is a generic SCSI property
> 
> 
> No it's not.
> 
> Havign a SCSI ID is a f*cking idiotic thing to do.
> 
> Only idiots like Joerg Schilling thinks that any such thing even _exists_. 
> It does not, never has, and never will.
> 
> The way you reach a SCSI device is through the device filename, and trying 
> to use controller/channel/id/lun naming IS INSANE!
> 
> Stop it now. We should kill that ioctl, not try to make it look like it is 
> sensible. It's not a sensible way to look up SCSI devices, and the fact 
> that some SCSI people think it is is doesn't make it so.
> 
> The fact is, you CANNOT ID a SCSI device that way. Look at how /sys does 
> it, and realize that there's a damn good reason we do it that way. We ID 
> the same device in many different ways, because different people want to 
> ID it differently.
> 
> You can ask "what's the first device we enumerated", you can ask "what's 
> the physical path to the device" or you can ask "what's the intrisic UUID 
> of the device". But the controller/channel/id/lun thing is just stupid. 
> You can look it up that way if you want to, but I refuse to have idiotic 
> interfaces that somehow try to make that the "official" name, when it 
> clearly is NOT.

Linus,
There are two things that really count:
  1) the identifier (preferably a world wide unique name)
     of the logical unit that is being addressed
  2) a topological description of how that logical unit
     is connected

For the last 25 years various OS SCSI subsystems have used
variants of 2) as a proxy for 1). Modern SCSI disks (and
soon SATA disks) have a world wide unique name associated
with their logical unit.

So why are modern SCSI standards full of terms like
I_T_L ** and I_T_L_Q nexus? Probably because the topology,
especially when there are multiple paths to the same
logical unit, is significant.

Linux's <hctl> may be a ham fisted way of describing
a path through a topology, but it easily beats /dev/sdabc
and /dev/sg4711 .
With a device node name like /dev/sdabc, a SCSI INQUIRY or
an ATA IDENTIFY DEVICE command can be sent to ascertain 1)
but I am unaware of any command sent to a logical unit that
will yield 2).


** that is: the nexus of an Initiator port, a Target port
   and a Logical unit number.

Doug Gilbert

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Linus Torvalds]

On Mon, 27 Mar 2006, Douglas Gilbert wrote:
>
> There are two things that really count:
>   1) the identifier (preferably a world wide unique name)
>      of the logical unit that is being addressed
>   2) a topological description of how that logical unit
>      is connected

And "SCSI ID" doesn't describe either.

> Linux's <hctl> may be a ham fisted way of describing
> a path through a topology, but it easily beats /dev/sdabc
> and /dev/sg4711 .

Sure, you can easily beat it by selecting what you compare it against.

But face it, /dev/sdabc or /dev/sg4711 simply isn't what you should 
compare against. What you should compare against is

	/dev/cdrom
	/sys/bus/ide/devices/0.0/block:hda/dev
	/dev/uuid/3d9e6e8dfaa3d116
	..

and a million OTHER ways to specify which device you're interested in.

The fact is, they can potentially all do the SCSI command set. And a "SCSI 
ID" makes absolutely zero sense for them (those three devices may be the 
same device, they may not be, they might be on another machine, who 
knows..)

> With a device node name like /dev/sdabc, a SCSI INQUIRY or
> an ATA IDENTIFY DEVICE command can be sent to ascertain 1)
> but I am unaware of any command sent to a logical unit that
> will yield 2).

AND NEITHER WILL SCSI_ID. So what the h*ll is your point?

If you want to know how the damn thing is physically connected, you want 
to use a path like

	/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/block:sda/dev

Note how, for example, this says 0:0:0:0, which happens to be the 
controller/channel/id/lun information for that "SCSI device". Notice how 
it is all zeroes? It's because that whole concept doesn't make any sense 
for things like USB storage, which has a totally different way to address 
the things.

But that thing really _does_ describe the physical location of that block 
device (actually, that particular file just contains the information about 
what the device node is for the device, but never mind).

And if you want to _use_ the device, you'd probably use a name like 
/dev/disk/by-path/usb-0F406C5032802890:0:0:0 (which is that same device, 
actually), or, more commonly /dev/disk/by-uuid/1468B594FC37ECF8, which 
happens to be the second partition on that physical device and which 
stays the same even when you plug that same disk in with firewire.

(Or, in this case, you migt actually want to use /dev/disk/by-label/rEFIt, 
which is that same partition on that USB device, but in a human-readable 
labeled form).

Again, the "SCSI ID" is a total and utter crock. IT HAS ABSOLUTELY NO 
VALID USE. It does _not_ describe what you claim it describes, and it is 
_not_ in any way superior to all the other ways of getting to that device.

		Linus

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Matthew Wilcox]

On Mon, Mar 27, 2006 at 09:15:35AM -0800, Linus Torvalds wrote:
> On Mon, 27 Mar 2006, Douglas Gilbert wrote:
> >
> > There are two things that really count:
> >   1) the identifier (preferably a world wide unique name)
> >      of the logical unit that is being addressed
> >   2) a topological description of how that logical unit
> >      is connected
> 
> And "SCSI ID" doesn't describe either.
> 
> > Linux's <hctl> may be a ham fisted way of describing
> > a path through a topology, but it easily beats /dev/sdabc
> > and /dev/sg4711 .
> 
> Sure, you can easily beat it by selecting what you compare it against.
> 
> But face it, /dev/sdabc or /dev/sg4711 simply isn't what you should 
> compare against. What you should compare against is
> 
> 	/dev/cdrom
> 	/sys/bus/ide/devices/0.0/block:hda/dev
> 	/dev/uuid/3d9e6e8dfaa3d116
> 	..
> 
> and a million OTHER ways to specify which device you're interested in.
> 
> The fact is, they can potentially all do the SCSI command set. And a "SCSI 
> ID" makes absolutely zero sense for them (those three devices may be the 
> same device, they may not be, they might be on another machine, who 
> knows..)

If this ioctl is generally supported, then you'll be able to find out if
they're all the same ;-)

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Linus Torvalds]

On Mon, 27 Mar 2006, Matthew Wilcox wrote:
> > compare against. What you should compare against is
> > 
> > 	/dev/cdrom
> > 	/sys/bus/ide/devices/0.0/block:hda/dev
> > 	/dev/uuid/3d9e6e8dfaa3d116
> > 	..
> > 
> > and a million OTHER ways to specify which device you're interested in.
> > 
> > The fact is, they can potentially all do the SCSI command set. And a "SCSI 
> > ID" makes absolutely zero sense for them (those three devices may be the 
> > same device, they may not be, they might be on another machine, who 
> > knows..)
> 
> If this ioctl is generally supported, then you'll be able to find out if
> they're all the same ;-)

Sorry, but no. You didn't read the other example in my email.

Many (most) Linux devices will actually have 0:0:0:0 in that field. 
Because the SCSI ID simply doesn't make sense to them, and they have none. 
So it's _not_ a unique ID.

For example, look at linux/block/scsi_ioctl.c, and realize that because I 
wanted to make sure that you could run "cdrecord dev=/dev/hdc", it does a 
few ioctl's that cdrecord wanted. In particular, it does 
SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER. Take a look at what it 
actually returns, and how it explicitly does NOT try to claim that those 
numbers "mean" anything.

The fact is, BUS/ID/LUN crap really doesn't make sense for the majority of 
devices out there. Never has, never will. The fact that old-fashioned SCSI 
devices think of themselves that way has absolutely zero to do with 
reality today.

If you want to know whether two devices are the same or not, you should do 
a "stat()" on the device node, and look at "st->rdev". No, it's not in any 
way guaranteed either, but it's actually a hell of a better rule than 
looking at ID/LUN information.

Trying to make more people use UUID's is the way to _really_ distinguish 
devices from each other.

			Linus

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Alan Cox]

On Llu, 2006-03-27 at 09:43 -0800, Linus Torvalds wrote:
> The fact is, BUS/ID/LUN crap really doesn't make sense for the majority of 
> devices out there. Never has, never will. The fact that old-fashioned SCSI 
> devices think of themselves that way has absolutely zero to do with 
> reality today.

It is still a very visible reality if you work in a data centre or with
server kit, or if you have tape arrays or multi-CD towers. The LUN or
device number in particular are generally the number emblazoned on each
slot in the unit and knowing the LUN reliably is sort of critical to not
making embarrasing (and career limiting) screwups when swapping drives.

Controller is a pretty abstract concept and except on arrays so is
device, but both device and LUN do need to be accessible reliably for
the hardware that thinks that way. What other hardware does is
irrelevant and "-EINVAL" seems as good an answer as anything.

Alan

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Douglas Gilbert]

Alan Cox wrote:
> On Llu, 2006-03-27 at 09:43 -0800, Linus Torvalds wrote:
> 
>>The fact is, BUS/ID/LUN crap really doesn't make sense for the majority of 
>>devices out there. Never has, never will. The fact that old-fashioned SCSI 
>>devices think of themselves that way has absolutely zero to do with 
>>reality today.
> 
> 
> It is still a very visible reality if you work in a data centre or with
> server kit, or if you have tape arrays or multi-CD towers. The LUN or
> device number in particular are generally the number emblazoned on each
> slot in the unit and knowing the LUN reliably is sort of critical to not
> making embarrasing (and career limiting) screwups when swapping drives.
> 
> Controller is a pretty abstract concept and except on arrays so is
> device, but both device and LUN do need to be accessible reliably for
> the hardware that thinks that way. What other hardware does is
> irrelevant and "-EINVAL" seems as good an answer as anything.

USB multi-card readers seem to like the concept of
LUNs as well.

Doug Gilbert
"What, never? Well, hardly ever." G+S HMS Pinafore

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Stefan Richter]

Douglas Gilbert wrote:
> Alan Cox wrote:
[host/ channel/ target/ LU enumeration...]
>> is still a very visible reality if you work in a data centre or with
>> server kit, or if you have tape arrays or multi-CD towers. The LUN or
>> device number in particular are generally the number emblazoned on each
>> slot in the unit
...
> USB multi-card readers seem to like the concept of LUNs as well.

Sure. The h:c:i:l tuple does not provide the LUN though, only an ersatz.
-- 
Stefan Richter
-=====-=-==- --== ===--
http://arcgraph.de/sr/

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Jan Engelhardt]

>[host/ channel/ target/ LU enumeration...]
>>> is still a very visible reality if you work in a data centre or with
>>> server kit, or if you have tape arrays or multi-CD towers. The LUN or
>>> device number in particular are generally the number emblazoned on each
>>> slot in the unit
>...
>> USB multi-card readers seem to like the concept of LUNs as well.
>
>Sure. The h:c:i:l tuple does not provide the LUN though, only an ersatz.

[For the list:]

..., only a replacement.


Jan Engelhardt
-- 

Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi

[Stefan Richter]

Bodo Eggert wrote:
> Having a SCSI ID is a generic SCSI property,

Most types of SCSI hardware do not have h:c:i:l style IDs like in the 
80's. The lower level drivers only make this tuple up to accomodate 
programming interfaces.
-- 
Stefan Richter
-=====-=-==- --== ==-==
http://arcgraph.de/sr/