Re: A Layered Kernel: Proposal

[Grigor Gatchev]

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.

> In the linux kernel I think that one of the most important things I've
> learned from it: middle layers are usually wrong.  Instead of hiding a
> device driver behind a middle layer, expose the low level device
> driver, but give it a library of common functions to build upon.  That
> way the driver is in control all the time and can use all the neat
> features of the hardware if it wants to, but for all the common tasks
> that have to be done, hand them over to the library.

By principle, the "least common denominator" type container layers are
bad, because of not being extendable; you are completely right here. A
class-like driver object model seems better to me. And the class-like
model is not the only one that is nicely extendable. You seem to be
knowledgeable on the topic - what driver object model would you suggest
for a driver layer model?


Grigor


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/