Messages in this thread | | | Date | Tue, 13 Sep 2005 11:25:56 +0100 | From | Christoph Hellwig <> | Subject | Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |