Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932383AbVI3FcV (ORCPT ); Fri, 30 Sep 2005 01:32:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932314AbVI3FcU (ORCPT ); Fri, 30 Sep 2005 01:32:20 -0400 Received: from thunk.org ([69.25.196.29]:61394 "EHLO thunker.thunk.org") by vger.kernel.org with ESMTP id S932291AbVI3FcT (ORCPT ); Fri, 30 Sep 2005 01:32:19 -0400 Date: Fri, 30 Sep 2005 01:31:49 -0400 From: "Theodore Ts'o" To: Luben Tuikov Cc: Linus Torvalds , Arjan van de Ven , Willy Tarreau , SCSI Mailing List , Andrew Morton , Linux Kernel Mailing List , Luben Tuikov , Jeff Garzik Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Message-ID: <20050930053149.GA22199@thunk.org> Mail-Followup-To: Theodore Ts'o , Luben Tuikov , Linus Torvalds , Arjan van de Ven , Willy Tarreau , SCSI Mailing List , Andrew Morton , Linux Kernel Mailing List , Luben Tuikov , Jeff Garzik References: <20050929232013.95117.qmail@web31810.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050929232013.95117.qmail@web31810.mail.mud.yahoo.com> User-Agent: Mutt/1.5.10i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2613 Lines: 53 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 - 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/