Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932385AbVI2X5a (ORCPT ); Thu, 29 Sep 2005 19:57:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932386AbVI2X5a (ORCPT ); Thu, 29 Sep 2005 19:57:30 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:16851 "EHLO e6.ny.us.ibm.com") by vger.kernel.org with ESMTP id S932385AbVI2X53 (ORCPT ); Thu, 29 Sep 2005 19:57:29 -0400 In-Reply-To: <20050929232013.95117.qmail@web31810.mail.mud.yahoo.com> Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel To: ltuikov@yahoo.com Cc: Andrew Morton , Arjan van de Ven , Jeff Garzik , Linux Kernel Mailing List , SCSI Mailing List , linux-scsi-owner@vger.kernel.org, Luben Tuikov , Linus Torvalds , Willy Tarreau X-Mailer: Lotus Notes Release 6.5.1IBM2 August 03, 2004 Message-ID: From: Prasenjit Sarkar Date: Thu, 29 Sep 2005 16:57:24 -0700 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 7.0|August 18, 2005) at 09/29/2005 19:57:27 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6297 Lines: 148 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 To Sent by: Linus Torvalds , linux-scsi-owner@ Arjan van de Ven vger.kernel.org cc Willy Tarreau , 09/29/2005 04:20 SCSI Mailing List PM , Andrew Morton , Linux Kernel Mailing List Please respond to , ltuikov@yahoo.com Luben Tuikov , Jeff Garzik Subject Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel --- Linus Torvalds 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 majordomo@vger.kernel.org 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 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/