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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/