From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Sun, 26 Mar 2006 22:30:51 UTC
Message-ID: <fa.HtedjIL8YvC5GmLxfL1CigIcBCY@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603261424590.15714@g5.osdl.org>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 00:07:46 UTC
Message-ID: <fa.5s7dZDQL9OXNqIZo4KlDte0p8hU@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603261602070.15714@g5.osdl.org>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 17:16:14 UTC
Message-ID: <fa.NWJ7FzovMZ1zx5OxX+R4QZRInVU@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603270854570.15714@g5.osdl.org>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 17:44:02 UTC
Message-ID: <fa.7SYdpli3PM9aUmnbkI+ObWm/a0o@ifi.uio.no>
Original-Message-ID: <Pine.LNX.4.64.0603270936290.15714@g5.osdl.org>

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