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:
> > 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.
[...]
> > 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
>
>
> > 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 <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:14 EST