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.
-
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
