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

[Luben Tuikov]

--- Linus Torvalds <torvalds@xxxxxxxx> wrote:
> 
> A "spec" is close to useless. I have _never_ seen a spec that was both big 
> enough to be useful _and_ accurate.
> 
> And I have seen _lots_ of total crap work that was based on specs. It's 
> _the_ single worst way to write software, because it by definition means 
> that the software was written to match theory, not reality.

A spec defines how a protocol works and behaves.  All SCSI specs
are currently very layered and defined by FSMs.

This is _the reason_ I can plug in an Adaptec SAS host adapter
to Vitesse Expander which has a Seagate SAS disk attached to phy X...
And guess what? They interoperate and communicate with each other.

Why?  Because at each layer (physical/link/phy/etc) each
one of them follow the FSMs defined in the, guess where, SAS spec.

If you take a SAS/SATA/FC/etc course, they _show you_ a link
trace and then _show_ you how all of it is defined by the FSM
specs, and make you follow the FSMs.

> So there's two MAJOR reasons to avoid specs:

Ok, then I accept that you and James Bottomley and Christoph are
_right_, and I'm wrong.

I see we differ in ideology.

>    It's like real science: if you have a theory that doesn't match 
>    experiments, it doesn't matter _how_ much you like that theory. It's
>    wrong. You can use it as an approximation, but you MUST keep in mind 
>    that it's an approximation.

But this is _the_ definition of a theory.  No one is arguing that
a theory is not an approximation to observed behaviour.

What you have here is interoperability. Only possible because
different vendors follow the same spec(s).

>  - specs have an inevitably tendency to try to introduce abstractions
>    levels and wording and documentation policies that make sense for a 
>    written spec. Trying to implement actual code off the spec leads to the 
>    code looking and working like CRAP. 

Ok, I give up: I'm wrong and you and James B are right.

>    The classic example of this is the OSI network model protocols. Classic 

Yes, it is a _classic_ example and OSI is _very_ old.

_But_ the tendency of representing things in a _layered_, object oriented
design has persisted.

>    spec-design, which had absolutely _zero_ relevance for the real world. 
>    We still talk about the seven layers model, because it's a convenient 
>    model for _discussion_, but that has absolutely zero to do with any 
>    real-life software engineering. In other words, it's a way to _talk_ 
>    about things, not to implement them.

Ok.
 
>    And that's important. Specs are a basis for _talking_about_ things. But 
>    they are _not_ a basis for implementing software.

Ok.  Let's forget about maintenance and adding _new_ functionality.
 
> So please don't bother talking about specs. Real standards grow up 
> _despite_ specs, not thanks to them.

Yes, you're right. Linus is always right.

Now to things more pertinent, which I'm sure people are interested in:

Jeff has been appointed to the role of integrating the SAS code
with the Linux SCSI _model_, with James Bottomley's "transport attributes".
So you can expect more patches from him.

Regards,
    Luben

P.S. I have to get this 8139too.c network card here working.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/