On 08/29/05 13:11, Christoph Hellwig wrote: > 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 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. Else you'll end up with another "HCIL"... (if you get the irony). > 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, If there's no userspace dependency, the kernel can do anything it wants. Since HCIL is SCSI Core crud, let SCSI Core invent HCIL tuples and support them. Luben > which is superceeded by sysfs but probably still has tons of users in > hardware probing, managment utilities and all kinds of userland. - : 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
