Hi Patrick,

On Mon, Jun 17, 2002 at 01:35:34PM -0700, Patrick Mansfield wrote:

On Sat, Jun 15, 2002 at 03:36:06PM +0200, Kurt Garloff wrote:

quoted

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.

I prefer we refer to the tuple as host, channel, id, lun (H, C, I, L), so
as to more closely match /proc/scsi/scsi, /proc/scsi/sg, and attached
messages:

You are refering to the naming of this 4-tuple, right: HCIL vs. CBTU?
I chose for CBTU, because that on's used in devfs. Actually, as you can see
from scsidev, I like HCIL more. But that's a detail the kernel should not
care about. The header line should be removed anyway as Albert remarked.
And helping those people who think that 200 bytes is unacceptable bloat.

[...]

quoted

3,0,12,00       0x00    1       sg12    c:15:0c sdf     b:08:50

Why not treat each upper layer driver the same? Type is already
in /proc/scsi/scsi, or implied by the upper level drivers attached.
Online should really be part of /proc/scsi/scsi.

I'm not sure I know what you mean. The fact that I decided to put
the sg device name first independently of the (potentially) random
order in which high-level drivers are assigned?

Then, each line is a path followed by a list of upper level devices.

It is. 

This would also simplify the code, although the ordering of the upper
level devices becomes link or module load order dependent.

Just I decided to report shg first. This has a very pratical reason:
I you want to use userspace tools to collect more advanced (and maybe type
dependant information), you will always want to use the sg device, which 
you can use to send SCSI commands and which you can open, even if there is
no medium or if the device is in use.

And similiar to sg (someone commented on parsing '^#'), have a _hdr
entry; something like:

$ cat /proc/scsi/map_hdr /proc/scsi/map

H:C:I:L      online  type:name:block/char:maj:min
00:00:00:00     1       sg:sg0:c:15:00      sr:sr0:b:0b:00
01:00:01:00     1       sg:sg1:c:15:01      sr:sr1:b:0b:01
01:00:02:00     1       sg:sg2:c:15:02      osst:osst0:c:ce:00
02:00:09:00     1       sg:sg3:c:15:03      sd:sdd:b:08:30

This looks find to me as well, by the way.
The reason why I chose to additionally report the device type reported by
inquiry is that you will only see the attached (and thus only the loaded)
high-level drivers of a device. With the device type, a userspace tool could
easily decide whether to trigger a modprobe and start again ...

Or:

H:C:I:L      online  type:enumeration:block/char:maj:min
00:00:00:00     1      sg:0:c:15:00      sr:0:b:0b:00
01:00:01:00     1      sg:1:c:15:01      sr:1:b:0b:01
01:00:02:00     1      sg:2:c:15:02      osst:0:c:ce:00
02:00:09:00     1      sg:3:c:15:03      sd:d:b:08:30

quoted

A patch for 2.5 should be done as well, if the design is OK, of course.

IMO, we should use driverfs for this in 2.5. Mike Sullivan's scsi driverfs
patch currently ends up with a driverfs layout (showing one Scsi_Device
with two partitions, sg and sd attached) like this:

I still think the easy /proc/scsi/map format would be a nice basis to
inquire more information on the SCSI devices from userspace, even if you add
hierarchical attachment information via driverfs. And I think a solution
that works with both 2.4 and 2.5 would help most users, of course.

Regards,
-- 
Kurt Garloff  [off-list ref]                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security