Martin Peschke3 wrote:
Doug, Providing udev names is great. Makes it more user-frendly.
Martin, It can still be tricked: for example putting disk device nodes in a /dev/disks/ directory. Also the udevinfo approach could be tricked by using mknod .
Btw., what do you think about this idea: If lsscsi was enhanced to provide certain transport specific attributes, as well, then a user could easily look up the Linux device name of a logical unit that he otherwise knows by its transport specific addressing, like WWPN and so on in case of Fibre Channel. That's desirable, because SAN management is done based on these transport specific addresses.
Yes, I did kick around this idea. After discussing some of the complexities, I thought it was better to do an incremental release. One problem is that lsscsi lists the attributes of logical units (i.e. linux SCSI "devices") and hosts (i.e. SCSI initiator ports). However most of the transport information available is bound to SCSI target device ports (and the target device holds one or more logical units). The logical unit may well have transport information but in a bridged environment it is the target's transport that sysfs is reporting. One question is whether to extend lsscsi to cover transports that carry SCSI command sets (e.g. SPI, FC, ATAPI, IEE1394, IB, IP and SAS (to name a few)) or to suggest someone write a lstransport utility. Obviously transports can carry payloads other than SCSI command sets.
I guess, this would require to convince James that it makes sense to spend effort on teaching either the midlayer or transport class to keep track of FCP_LUNs, or 64 bit LUNs respectively :)
There is probably enough transport information there already in sysfs (but some "back" symlinks would be handy). Increasing the degree of difficulty is the lack of uniformity between transport sysfs representations. The proposed SAS sysfs representation will increase this entropy. I am beginning to see why the (maligned) SDI ioctl interface for SAS HBAs has a <h:c:t:l> tuple to SAS address map. It is the <h:c:t:l> tuple (or subsets of it) that holds lsscsi together. Doug Gilbert - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
