From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: A Layered Kernel: Proposal
Date: Wed, 25 Feb 2004 21:59:32 -0800 [thread overview]
Message-ID: <20040226055932.GB8910@pegasys.ws> (raw)
In-Reply-To: <Pine.LNX.4.44.0402252133300.18217-100000@lugburz.zadnik.org>
On Wed, Feb 25, 2004 at 09:46:59PM +0200, Grigor Gatchev wrote:
>
>
> On 25 Feb 2004, Christer Weinigel wrote:
>
> > Just because there's an academic paper written about something doesn't
> > mean that its right. For once Richard is partially right, unneccesary
> > layering can really ruin a system. Grigor said that in 25 years he
> > has seen few cases of pretty code performing badly, but look at the
> > failure of SysV streams, it's a really pretty layering model, but in
> > practice it turns out to be too slow for most anything useful.
> >
> > It's not too uncommon with drivers that breaks just because the actual
> > hardware won't fit into the model that is exposed via a layer. For
> > example, look at the error recovery of the old Linux SCSI code: it's
> > hard to do proper error recovery, and it is much slower than it needs
> > to because first the low level driver tries to do error recovery and
> > later on the higher layers try to do error recovery too. Multiply a
> > couple of retries in the SCSI middle layer with another couple of
> > retries after a timeout a few seconds at the SCSI controller layer and
> > you have a model where it takes a minute to do figure out that
> > something is wrong, for something that ought to take just a few
> > seconds.
> >
> > Additionally, because of the strict layering it's not always possible
> > to hand up a meaningful error status from the lower layers to the
> > higher layers, it gets lost in the middle just because it didn't fit
> > into the layers model of the world. It can also mean that it's not
> > possible to use the intelligent features of a smart SCSI controller
> > that can do complex error recovery on its own since most layers end up
> > exposing only the "least common denominator".
>
> I may be wrong, but this description seems to me more like an example for
> bad design and implementation rather than for a bad general idea.
It may be both. I don't think the resistance is to layering
as a general idea. The resistance is to rigidly (read
explicitly) defined layers.
The 7 (if my memory serves) layer ISO networking definition is
perhaps a better example. I can't recall hearing of any
implementation with decent performance that conforms to the
ISO definition of the layer boundaries.
What seems a good boundary at one time will likely prove a
poor one later. Or what may be good in the general can slow
down the whole system because of one specific subsection
where it is suboptimal.
The best is to keep layering in mind (which is already the
case) but to remain flexible, functional specific and
mutable.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
next prev parent reply other threads:[~2004-02-26 5:59 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-24 20:05 Grigor Gatchev
2004-02-24 22:31 ` Rik van Riel
2004-02-25 9:08 ` Grigor Gatchev
2004-02-25 12:52 ` Rik van Riel
2004-02-25 13:23 ` Richard B. Johnson
2004-02-25 15:08 ` Grigor Gatchev
2004-02-25 15:42 ` Richard B. Johnson
2004-02-25 16:01 ` Nikita Danilov
2004-02-25 19:25 ` Christer Weinigel
2004-02-25 19:46 ` Grigor Gatchev
2004-02-25 23:40 ` Timothy Miller
2004-02-26 0:55 ` Rik van Riel
2004-02-26 15:43 ` Jesse Pollard
2004-02-26 17:12 ` Rik van Riel
2004-02-27 9:45 ` Grigor Gatchev
2004-02-26 11:03 ` Grigor Gatchev
2004-02-26 5:59 ` jw schultz [this message]
2004-02-29 12:32 ` Christer Weinigel
2004-02-29 14:48 ` Grigor Gatchev
2004-03-01 6:07 ` Mike Fedyk
2004-03-06 18:51 ` Grigor Gatchev
2004-03-08 3:11 ` Mike Fedyk
2004-03-08 12:23 ` Grigor Gatchev
2004-03-08 17:39 ` Theodore Ts'o
2004-03-08 20:41 ` viro
2004-03-09 19:12 ` Grigor Gatchev
2004-03-09 21:03 ` Timothy Miller
2004-03-09 23:24 ` Mike Fedyk
2004-03-08 18:41 ` Mike Fedyk
2004-03-08 21:33 ` Paul Jackson
2004-02-25 14:44 ` Grigor Gatchev
2004-02-24 22:54 ` Mike Fedyk
2004-02-25 10:03 ` Grigor Gatchev
2004-02-25 19:58 ` Mike Fedyk
2004-02-25 21:59 ` Grigor Gatchev
2004-02-25 22:22 ` Mike Fedyk
2004-02-26 11:46 ` Grigor Gatchev
2004-02-26 12:17 ` Jens Axboe
2004-02-26 16:37 ` Grigor Gatchev
2004-02-26 18:12 ` Christoph Hellwig
2004-02-26 19:23 ` Mike Fedyk
2004-02-27 11:18 ` Grigor Gatchev
2004-02-27 18:05 ` Tim Hockin
2004-02-27 18:34 ` Richard B. Johnson
2004-02-27 18:27 ` Mike Fedyk
2004-02-28 0:26 ` Rik van Riel
2004-02-24 20:28 Carlos Silva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040226055932.GB8910@pegasys.ws \
--to=jw@pegasys.ws \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®