On Fri, Aug 26, 2005 at 03:24:06PM -0400, Jeff Garzik wrote: > Luben Tuikov wrote: > >Even simpler: the transport layer, calls SCSI Core, saying: "Hey here is > >a pointer to struct scsi_domain_device. If you want, you an send REPORT > >LUNS and other things to it." > > For the SG_IO ioctl, /dev/sg and request_queue usage, SCSI core must map > an address (currently HCIL) into a scsi_domain_device pointer. These > upper layer kernel elements rely on this "SCSI address", and rely on the > fact that SCSI core can route from a block device straight to a SCSI > LLD, using nothing more than this "SCSI address."
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 a huge backwards-compatiblity issue - we'll probably have to support the old variant forever. Besides that there's probably only SCSI_IOCTL_GET_IDLUN, which is superceeded by sysfs but probably still has tons of users in hardware probing, managment utilities and all kinds of userland. - 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
