microkernels

[Eric W. Biederman]

Francois-Rene Rideau <fare@tunes.org> writes:

<snip lots of the microkernel vs monolithic & nokernel design>

1)  Micro kernels look good for hard realtime systems:
    A) The source code is smaller and easier to prove and verify, and predict.
    B) Mach doesn't fit my definition of a useable microkernel because
       it still has hardware drivers in the kernel.

2) Monolithic kernels look good for general systems:
   A) Functionally is exported at a higher level, so mistakes in the initial
      abstraction can be corrected. vs. Microkernels which must get it right 
      the first time.

3) No kernel design looks decent on paper but
   A) What the definition leaves off what level interface you are exporting/supporting.
   B) A single address space loses some fault tolerance over current systems.
      In particular a bug in the prover, can let through software that can let a 
      stray pointer take down the system.
      And the bug can be caused by a 1 time hardware malfunction. . .
   C) How to support paging, process control and many of the traditional 
      kernel functions is unclear.
   D) Very aggresive optimizers are notoriously buggy.
   E) On current hardware the main cost of a cost of a context switch
      is losing cache, and tlb state.  Monolithic kernels handle this quite well.
   F) The no kernel argument is one for moving correctness proving from hardware
      to software.  As hardware can do things in parallel, and software is restricted
      to serial operation this is not a clear win.
   G) I obviously think the no kernel design hasn't been proven a doable yet.

Eric