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 <[email protected]>
---
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
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.
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?
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.
> 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)
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
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/
>> 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
--
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
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
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
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
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.
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
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
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 ;-)
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
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
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
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/
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
>[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
--