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 Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security