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