Re: [PATCH 2.6.13 14/14] sas-class: SCSI Host glue

[Sergey Panov <sipan@sipan.org>]

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.



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