Re: [PATCH] minimal SAS transport class

[Luben Tuikov <luben_tuikov@adaptec.com>]

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.