public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Grigor Gatchev <grigor@serdica.org>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
	Christer Weinigel <christer@weinigel.se>,
	linux-kernel@vger.kernel.org
Subject: Re: A Layered Kernel: Proposal
Date: Mon, 8 Mar 2004 12:39:40 -0500	[thread overview]
Message-ID: <20040308173940.GD5263@thunk.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0403081311020.21912-100000@lugburz.zadnik.org>

On Mon, Mar 08, 2004 at 02:23:43PM +0200, Grigor Gatchev wrote:
> 
> Also, does "think API changes, nothing generalised *at all*" mean anything
> different from "think code, no design *at all*"? If this is some practical
> joke, it is not funny. (I can't believe that a kernel programmer will not
> know why design is needed, where is its place in the production of a
> software, and how it should and how it should not be done.)

So give us a design.  Make a concrete proposal.  Tell us what the
API's --- with C function prototypes --- should look like, and how we
should migrate what we have to your new beautiful nirvana.

Engineering is the task of trading off various different principals;
in general it is impossible to satisfy all of them 100%.  For example,
Mach tried to be highly layered, with strict memory protections to
protect one part of the kernel from another --- all good things, in a
generic sense.  Streams tried to be extremely layered as well, and had
a design that a computer science professor would love.  Both turned
out to be spectacular failures because their performance sucked like
you wouldn't believe.

Saying "layered programming good" is useless.  Sure, we agree.  But
it's not the only consideration we have to take into account.
Furthermore, the Linux kernel has a decent amount of layering already,
although it is a pragmatist's sort of layering, where we use it when
it is useful and ignore when it gets in the way.  Given your
high-level descriptions, perhaps the best description of what we
currently have in Linux is that it uses a C-based (because no one has
ever bothered to create a C++ obfuscated contest --- it's too easy),
multiple-inheritance model, where each device driver can use
common-denominator code as necessary (from the PCI sublayer, the tty
layer, the SCSI layer, the network layer, etc.), but it is always
possible for each driver to provide specific overrides as necessary
for the hardware.

Is my description of Linux's device model accurate?  Sure.  Is it
useful in terms of telling us what we ought to do in order to improve
our architecture?  Not really.  It's just a buzzword-compliant,
high-level description which is great for getting great grades from
clueless C.S. professors that are more in love with theory than
practice.  But that's about all it's good for.

In order for it to be at all useful, it has to go to the next level.
So if you would like to tell us how we can do a better job, please
submit a proposal.  But it will have to be a detailed one, not one
that is filled with high-level buzzwords and hand-waving.

					- Ted


  reply	other threads:[~2004-03-08 17:40 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-24 20:05 A Layered Kernel: Proposal 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
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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=20040308173940.GD5263@thunk.org \
    --to=tytso@mit.edu \
    --cc=christer@weinigel.se \
    --cc=grigor@serdica.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    /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