On Mon, Aug 29, 2005 at 01:20:50PM -0400, Luben Tuikov wrote: > > What's a scsi_domain_device? Anyway, we don't need any HCIL tuple for > > all of the above. SG_IO is done on a blockdevice node, /dev/sg is done > > on a chardevice node. Each of them are attached to a request_queue that's > > known at the time their ->probe routine is setup - no need for HCIL here > > _at all_. There's actually only few userland interfaces that use HCIL > > addressing: the scanning through /sys/.../scan (or the old /proc/scsi/scsi > > variant), using WWNs for FC and SAS here would be much nicer, but there's > > WWNs *must not* be visible _at_all_ to anyone above the SAS layer, in the > kernel. That is, the transport addressing method *must not* be visible to > SCSI Core or anyone above it, in the kernel.
Please read the sentence again. I said accept them in the scan attribute, that does _NOT_ mean adding knowledge to the scsi layer. In fact if you through the linux-scsi archives about the problems those attributes had with the FC transport class I suggested moving the parsing of these attributes into the transport class, which would be the preferred method to implement this. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
