In a conversation that began as a request to include the SAS Transport Layer [1] in the mainline Linux kernel, there was an interesting thread regarding specifications. Linux creator Linus Torvalds began the discussion saying, "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."
Linus went on to list two reasons to avoid specifications when writing software. First, "they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW." Second, "specs have an inevitable 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." As a "classic example" he pointed to the OSI model [2], "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. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."
From: Linus Torvalds [email blocked] To: Arjan van de Ven [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Thu, 29 Sep 2005 12:57:05 -0700 (PDT) On Thu, 29 Sep 2005, Arjan van de Ven wrote: > > a spec describes how the hw works... how we do the sw piece is up to > us ;) How we do the SW is indeed up to us, but I want to step in on your first point. Again. 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. So there's two MAJOR reasons to avoid specs: - they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None. 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. - 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. The classic example of this is the OSI network model protocols. Classic 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. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software. So please don't bother talking about specs. Real standards grow up _despite_ specs, not thanks to them. Linus
From: Luben Tuikov [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Thu, 29 Sep 2005 16:20:13 -0700 (PDT) --- Linus Torvalds [email blocked] 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.
From: Linus Torvalds [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Thu, 29 Sep 2005 17:35:27 -0700 (PDT) On Thu, 29 Sep 2005, Luben Tuikov wrote: > > > 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. No. A scientific theory is an approximation of observed behaviour WITH NO KNOWN HOLES. Once there are known holes in the theory, it's not a scientific theory. At best it's an approximation, but quite possibly it's just plain wrong. And that's my point. Specs are not only almost invariably badly written, they also never actually match reality. At which point at _best_ it's just an approximation. At worst, it's much worse. At worst, it causes people to ignore reality, and then it becomes religion. And that's way _way_ too common. People who ignore reality are sadly not at all unusual. "But the spec says ..." is pretty much always a sign of somebody who has just blocked out the fact that some device doesn't. So don't talk about specs. Talk about working code that is _readable_ and _works_. There's an absolutely mindbogglingly huge difference between the two. Linus
From: Theodore Ts'o [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Fri, 30 Sep 2005 01:31:49 -0400 On Thu, Sep 29, 2005 at 04:20:13PM -0700, Luben Tuikov wrote: > > A spec defines how a protocol works and behaves. All SCSI specs > are currently very layered and defined by FSMs. A spec defines how a protocol works and behaves --- *if* it is well-specified and unambiguous, and *if* vendors actually implement the spec correctly. (And sometimes vendors have major economic incentives to cheat and either intentionally violate the specification, or simply not bother to test to make sure whether or not they implemented their hardware correctly.) Computing history has been literred with specifications that were incompentently written and/or incompentently implemented --- from the disaster known as ACPI, to FDDI (early FDDI networking gear was interoperable only if you bought all of your gear from one vendor, natch), consumer-grade disks which lied about when data had been safely written to iron oxide to garner better Winbench scores, and many, many, many others. This is one of the reasons why the IETF doesn't bless a networking standard until there are multiple independent, interoperable implementations --- and even _then_ there will be edge cases that won't be caught until much, much later. In those cases, if you implement something which is religiously adherent to the specification, and it doesn't interoperate with the real world (i.e., everybody else, or some large part of the industry) --- do you claim that you are right because you are following the specification, and everyone else in the world is wrong? Or do you adapt to reality? People who are too in love with specifications so that they are not willing to be flexible will generally not be able to achieve complete interoperability. This is the reason for the IETF Maxim --- be conservative in what you send, liberal in what you will accept. And it's why interoperability testing and reference implementations are critical. But it's also important to remember when there is a reference implementation, or pseudo-code in the specification, it's not the only way you can implement things. Very often, as Linus has pointed out, there are reasons why the pseudo-code in the specification is wholely inappropriate for a particular implementation. But that's OK; the implementation can use a different implementastion, as long as the result is interoperable. Regards, - Ted
Related Links:
- Archive of above thread [3]