Re: /proc/scsi/map

Andries.Brouwer@cwi.nl
Sat, 15 Jun 2002 23:54:12 +0200 (MEST)


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