On Tue, 2005-09-13 at 09:40 -0600, Matthew Wilcox wrote: > On Mon, Sep 12, 2005 at 06:00:15PM -0400, Luben Tuikov wrote: > > "transport attribute class" is just an _attribute_ class, Christoph. > > "transport layer" is a lot more involved. I sincerely hope > > you can see this. E.g. domain discovery belongs in the transport > > layer. In SPI, LLDDs did it; in MPT the firmware does it. > > LLDDs having their own domain discovery code is definitely a misfeature. Unfortunatly it is impossible to have one discovery code shared by all LLDD under the same transport -- in FC world, Qlogic does "remote ports" discovery in FW, Emulex does it in LLDD. Both approaches have benefits and drawbacks, but it would be hard, if not impossible to move Emulex discovery code into FC transport and to force Qlogic to use it, because Qlogic HBA are not designed for doing discovery in the driver. But the fact that Qlogic does discovery in FW/ASIC does not turn Qlogic HBAs into SPI. I expect the same is true in SAS -- even though MPT cards do discovery on the card, those SAS cards can not masquerade as a SPI cards (well, in theory, it is possible, but ...). > As you know, stuff is being rearranged to move more of the SPI-specific > code from both SCSI core and LLDDs into the SPI transport. I suspect > domain discovery will always be triggered by the LLDD for SPI, but at > least a driver doesn't have to have its own code to do that any more. Only if it can be turned into a some sort of library LLDD may use if it needs it. But it is only makes sense to move that code out of the LLDD and into the transport module, if more then one LLDD can make use of it. Sergey Panov ====================================================================== Any opinions are personal and not necessarily those of my former, present, or future employers. - : 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
