Luben,
The role of standard bodies is to primarily enforce interoperability but
while they suggest FSMs and layering, those directives are not mandatory.
I have also seen industrial SCSI Core implementations from various sources
to come to the following conclusions (i) they do not implement all the
manadatory stuff (ii) they implement just enough to get by with
interoperability [who has the time] (iii) any layering design is
evolutionary and (iv) none of them come close to the T10 FSMs.
You may disagree, but there needs to be a balance between standards and
implementations.
Luben Tuikov
<[email protected]
m> To
Sent by: Linus Torvalds <[email protected]>,
linux-scsi-owner@ Arjan van de Ven
vger.kernel.org <[email protected]>
cc
Willy Tarreau <[email protected]>,
09/29/2005 04:20 SCSI Mailing List
PM <[email protected]>,
Andrew Morton <[email protected]>,
Linux Kernel Mailing List
Please respond to <[email protected]>,
[email protected] Luben Tuikov
<[email protected]>, Jeff
Garzik <[email protected]>
Subject
Re: I request inclusion of SAS
Transport Layer and AIC-94xx into
the kernel
--- Linus Torvalds <[email protected]> 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-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |