Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

[Jeff Garzik <jgarzik@pobox.com>]

Luben Tuikov wrote:
> On 10/04/05 10:54, Jeff Garzik wrote:
>
> > Luben Tuikov wrote:
> >
> >
> > > The reason of all this hoopla is that James B, wants to decree
> > > that LSI/MPT is the norm and everything else (USB/SAS/SBP) is
> > > the exception, while in fact it is the other way around.
> >
> >
> > False.  You continue to misunderstand basic stuff about the SCSI core.
>
>
> Let me repeat: LSI/MPT is not the norm and USB/SAS/SBP, i.e. having
> an actual transport layer (handling transport tasks, and error recovery)
> is the norm.
>
> Don't make stupid bullshit generalizations that I "continue to
> misunderstand basic stuff about the SCSI core".

You continue to misunderstand everyone else's opinion.  No one is 
claiming that LSI/MPT is the norm.

The claim is that the transport class is the method through which a 
transport layer is plugged into the SCSI stack.  Pluggable transport 
classes means that SAS transport layer details go into the SAS transport 
class (or a helper lib).  SPI (parallel/legacy SCSI) transport layer 
details should move to the SPI transport class.


> I've probably misunderstood that LUNs are 32 bit (since SCSI Core
> says so) and that REQUEST SENSE clears ACA?

You misunderstood that everybody, but you, has moved on to the "what do 
we do about this" phase.


> But since the layers are completely upside down one compared
> to the other, it would be quite messy unless you can separate
> the implementations and at one or the other (but not both)
> include a basic emulator.  If there is no basic emulator then
> that part would have to be taken by the LLDD.

Nothing is upside down.  Transport details plug into an obvious location 
-- the transport class, and associated helper libs (if any).

	Jeff


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