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

[Jeff Garzik <jgarzik@pobox.com>]

Stefan Richter wrote:
> Arjan van de Ven wrote:
>
> > On Thu, 2005-09-29 at 06:04 +0200, Willy Tarreau wrote:
> >
> > > On Wed, Sep 28, 2005 at 07:04:31PM -0400, Jeff Garzik wrote:
> > >
> > > > Linux is about getting things done, not being religious about 
> > > > specifications.  You are way too focused on the SCSI specs, and 
> > > > missing the path we need to take to achieve additional flexibility.
>
>
> AFAIU, demands to get our concepts closer to SAM concepts are actually 
> motivated by this: To achieve additional flexibility. (In particular, to 
> ease integration of the various transports.)

That's what transport classes help achieve.

We just gotta move gunk from the core (HCIL etc.) to scsi_transport_spi 
before we get there.


> We implement drivers of initiators. (Well, targets too.) The specs 
> describe _what_ initiators do. Thereby they partly describe _how_ 
> drivers of initiators (our sw pieces) work.

Mostly agreed.  Some of the firmware-based and emulated SCSI stuff is a 
bit of an I_T mix.


> However it is very desirable to reflect layers and concepts of the SAM 
> in our stack. One class of reasons is maintainability. No person is able 
> to understand the stack; nor is a person able to consume and understand 
> all or even half of the SCSI specs. No person is able to construct a 
> mapping between the whole stack and the whole SCSI-3 Architecture Model 
> (in his mind or with pencil and paper...). Therefore there have to be 
> _components_ of the stack's architecture model which map 1:1 to 
> _components_ of the SCSI-3 Architecture Model.
>
> Fortunately, SAM layers and concepts are already there in the stack, 
> although incomplete and incoherent. It will always be disputable _how_ 
> complete and coherent our software should be in this respect. However it 
> is out of a question that our software's architecture model might 
> arbitrarily differ from the SAM.

I think just about everybody agrees with this.

The current thread is more about the path to take, to get there...

The general point about specs is that you gotta think about them, not 
just blindly implement them.  SNIA for example is notorious for 
generating silly storage-related specifications.  And some of the T10 
stuff is... well... obviously designed by committee :)

	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/