On Thu, 2007-06-21 at 18:46 +0200, Stefan Richter wrote: > For example, the SCSI midlayer H:C:T:L tuple is useless for > SBP-2-attached devices. What is useful is the ieee1394_id sysfs > attribute which we expose as a scsi_device's sysfs attribute. This > attribute was something implementation-defined until now, but I changed > it to the concatenation of target port identifier and logical unit > identifier for Linux 2.6.22, as per SAM(-4) annex A. (That change is > merely an alternative format for the old sbp2 driver and the only format > for the new fw-sbp2 driver.) > > Or did I miss something and there is already a mechanism for transports > to expose target/LU identifiers? So that userland doesn't have to care > what transport it is, except as far as the details of the identifiers' > formats are concerned? H:C is really mid-layer defined (although I'd like to get rid of C eventually). They really correspond to physical enumeration of the HBA devices. T (or I) is the one we think could be abstracted and placed within the gift of the transport, but so far there's been a lot of debate with few actual concrete proposals. L is basically defined by SAM for every transport, but I'm really unsure how it should be represented in all its SAM specified glory. James - To unsubscribe from this list: 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
