adding PCI bus information to SCSI layer
Quoted 13 lines · Matt Domsch
I'm working on an IA-64 user-space application to add a Linux entry to the IA-64 boot manager. To do so, I've got to uniquely identify a disk by it's controller PCI address, SCSI channel,
ID, and LUN. Essentially, I need to tie/dev/sdato an EFI device. An equivalent problem (with similar solution) exists with i386 where the BIOS boot order is not necessarily the Linux driver load order.BIOS Enhanced Disk Drive Services 3.0 provides a way to query BIOS for what it thinks is it's device location and order. IA-64 implements EDD 3.0, and some i386 BIOS manufactures are adding this feature also. EDD 3.0 information is available at http://www.t13.org.
Quoted 7 lines
What I'd like to do is add the PCI location of the SCSI controller to the information printed in
/proc/scsi/scsi, as follows:Attached devices:
Host: scsi0 Channel: 00 Id: 05 Lun: 00 PCI bus: 1 slot: 6 fn: 0
Vendor: NEC Model: CD-ROM DRIVE:466 Rev: 1.06
Type: CD-ROM ANSI SCSI revision: 02
[snip]
Matt,
SANE (and probably some other applications) parses the output of 'cat /proc/scsi/scsi' so any change to its format may trip SANE up. How about another entry in the /proc/scsi directory that has a more parsable format (e.g. xml :-) ).
Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack.
Doug Gilbert
Quoted 4 lines
Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack.
An ioctl might be better. We already have an ioctl for querying the lun information for a disk. We could also return the bus information for its controller(s) [remember multipathing]
Quoted 1 line
Quoted 9 lines · Alan Cox
Quoted 5 lines
Also ISA adapters are not the only non-PCI adapters, there are the growing band of pseudo adapters that may or may not have a PCI bus at the bottom of some other protocol stack.
An ioctl might be better. We already have an ioctl for querying the lun information for a disk. We could also return the bus information for its controller(s) [remember multipathing]
Both 'cat /proc/scsi/scsi' and ioctls used on fds belonging to the existing upper level drivers (e.g. sd and sr) have a problem as far as getting HBA environment information: there needs to be at least one SCSI device (target) connected to the HBA. With no SCSI devices connected, there is no fd to do an ioctl on. [The same problem arises if a device is there but marked offline, has an exclusive lock on it, ...]
Perhaps Matt could look at the approach I have taken with the scsimon experimental upper level driver. Scsimon was originally designed to get scsi based information to the /sbin/hotplug mechanism. It also supplies ioctls to probe HBAs as well as SCSI devices. More information about it can be found at:
http://www.torque.net/scsi/scsimon.html
It should not be difficult to add HBA PCI bus information to scsimon (after the Scsi_Host structure is expanded to hold that information).
Doug Gilbert