Re: A Layered Kernel: Proposal

[Christer Weinigel]

Nikita Danilov <Nikita@xxxxxxxxxxx> writes:

> Richard B. Johnson writes:
> 
> [...]
> 
>  > 
>  > So don't claim that layering does anything useful except
>  > to create jobs. It is a make-work technique that creates
>  > jobs for inadequate or incompetent programmers.
> 
> Interesting that whole notion of layering and separation of concerns was
> invented exactly during the design of "THE" OS kernel. By very competent
> and adequate programmer.
> 
> http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD196.PDF

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".

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.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@xxxxxxxxxxx>  http://www.weinigel.se
-
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/