Can we really think at a new OS design nowadays ?

[Neal H. Walfield]

At Sun, 6 Aug 2006 09:52:51 +1000,
Benno wrote:
> On Sat Aug 05, 2006 at 19:50:05 +0200, Guillaume FORTAINE wrote:
> >
> >Abstraction will be the solution,
> 
> Doesn't the research of Engler show us that abstraction in operating
> system design is bad?

I think it would be fair to argue that this is perhaps the hypothesis
which drove the Exokernel research, however, it is unclear to me that
the research actually proves.

In "Application Performance and Flexibility on Exokernel Systems,"
Kaashoek et al. state that hardware page tables, although they impose
policy and appear to restrict application freedom, do not actually
significantly reduce application flexibility:

  "Unlike the MIPS architecture, the x86 architecture defines the
  page-table structure.  Since x86 TLB refills are handled in
  hardware, this structure cannot be overridden by applications. . . .
  Although these restrictions make Xok less extensible than Aegis,
  they simplify the implementation of libOSes with only a small
  reduction in application flexiblity (9)."

In fact, it simplified thigs:

  "User-level page tables made the implementation of libOSes tricky on
  Aegis; since the x86 has hardware page tables, this issue
  disappeared on Xok/ExOS (16)."

I draw from this that eliminating abstractions simply to eliminate
abstractions misses an important point: some polices introduced via
mechanism have negligible negative impact on performance and some such
policies actually have positive impact (e.g. code simplification).
This observation supports Liedtke in his challenge of the Exokernel
architecture in "On u-Kernel Construction:"

  "In contract to our approach [L4], [Exokernel] is based on the
  philosophy that a kernel should /not/ provide abstractions but only
  a minimal set of primitives.  Consequently, the Exokernel interface
  is architecture dependent . . .  We believe that dropping the
  abstractional [sic] approach could only be justified by substantial
  performance gains. . . . It might turn out that the right
  abstractions are even more efficient than securely multiplexing
  hardware primitives or, on the other hand, that abstractions are too
  inflexible."

Neal