From: Ian King (iking_at_killthewabbit.org)
Date: Wed Jan 21 2004 - 09:27:39 PST
This paper describes an operating system structure called an exokernel, that
places most traditional operating system functionality in user space instead of
in a protected core. This is distinct from either a monolithic kernel, in which
all "system" functionality exists in the protected kernel space, or a
microkernel architecture, which depends on privileged server routines for system
features. The authors describe the principles of an exokernel, making liberal
reference to other papers, then describe and benchmark their implementation on
Pentium Pro x86 hardware. Existing software, written for UNIX systems, is
compiled with little or no modification, given the conscious emulation of UNIX
system calls by the exokernel system. The exokernel compares favorably with
traditional operating systems on identical hardware. Reference is made to
earlier, similar implementations on other hardware (MIPS).
The concept of the exokernel is in some ways another example of "drawing the
lines" in one place or another - for instance, a monolithic kernel draws the
lines of functionality around all system features, and incorporates everything
into a single protected space. A microkernel defines a lesser set of
functionality for that core, but defines other privileged spaces and
kernel-mandated control mechanisms for the remainder of system features. The
exokernel takes an approach superficially similar to that of the microkernel,
but distinct in that the privileged servers of a microkernel architecture are
not present. Instead, user applications manage such mid- and high-level
resources as file systems (this paper focused heavily on file system
implementation). As I read it, the "lines" are drawn much lower in the
hierarchy of functionality; using file systems as an example, the kernel owns
security and synchronization of accesses to the actual storage devices, but the
applications implement everything above the block/buffer page level.
This could be quite arduous for the application developer, but the model
explained here includes user-space libraries that provide "typical"
functionality - in this implementation, paralleling typical UNIX features. (In
addition to making for ease of understanding, it also facilitated benchmarking
against known UNIX implementations through use of existing programs.) Part of
the stated appeal of exokernel systems, however, is that it is quite
straightforward for a particular application to write its own file system or
file types, or create unexpected relationships between objects; for instance, in
the HTTP server that is described, the ease of moving from disk block buffers to
network buffers facilitates throughput.
Protection is implemented through "software regions", which sound very similar
to protection domains in Opal; permissions are gained through traditional
capabilities. The use of read-only software regions allows applications to
readily access kernel structures, which it is argued aids in both performance
and correctness of shared object semantics. Interestingly, the authors place
considerable emphasis on recovery from system crashes, and show how an exokernel
system facilitates quick, accurate recovery.
It is always helpful to see implementation notes that describe challenges and
drawbacks, and this paper is reasonably forthcoming in this regard. The
performance comparisons were based on simple and direct measurement that, while
arguably lacking in sophistication and depth, are easily reproducible and
understandable; they are compelling because of their simplicity and real-world
nature (e.g. delivering Web pages is a common, clearly understood function).
When performance metrics or methods are overly complicated, I often question
whether they really provide insight into the questions being asked.
This archive was generated by hypermail 2.1.6 : Wed Jan 21 2004 - 09:57:12 PST