Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

[Christoph Hellwig <hch@infradead.org>]

On Mon, Sep 12, 2005 at 04:17:48PM +1000, Douglas Gilbert wrote:
> FreeBSD threw out their original SCSI design and replaced it
> with CAM circa 1998. CAM has its problems but I would guess
> a modern SAS LLDD would have less "impedance mismatch" (sorry
> about the gibberish) than what Luben is now facing.

Their code doesn't scale well to current needs at all.  Please look
at the freebsd-scsi list and all the problems they have with things
like FC or iSCSI.  Or no support for REPORT_LUNs at all.  While I
wouldn't say we have the best thing since slided bread it's certainly
not as bad as some people would like to make it.

> If we look at our (im)famous <h:c:i:l> addressing string,
> the first 2 elements (i.e. "h:c") are about kernel device
> addressing (i.e. which (part of a) HBA to be initiator); the
> contentious "i" is about addressing the target and is
> transport dependent, and the "l" is for addressing within
> the target. Only the last element is true SCSI and is
> defined in SAM (to be 64 bits, not 32). In iSCSI the "i"
> is actually an adorned IP address.
> 
> So the kernel "discovers" at the "h:c" level at powerup
> (and at runtime with hotplug events); leaving the SCSI
> subsystem to do discovery at the "i" and the "l" level.

That's not true at all.  Neither is 100% mandatory in the
scsi level.  As Luben's code shows you can just call scsi_add_device
and do everything yourself.  That is nice for LLDDs that don't
fit into SAM at all like integrated RAID HBAs.  Besides that we
support a library function to do the "l" part that can be used by
transport classes or drivers.  There's a library function to do
the "i" part brute-force for SPI and modelled after SPI devices that
is still in scsi_mod.ko but isn't integrated with the core code
in any way.  Before 2.6 the predessor to this function
"scsi_scan_host" was called for every registered host, but we
fortunately got rid of that.