From: Reid Wilkes (reidwilkes_at_verizon.net)
Date: Tue Jan 20 2004 - 23:18:13 PST
This is the first time I have ever heard of or been exposed to the ideas of
an exokernel, so my experience here is somewhat limited. It seems that the
basic idea of the exokernel is that the microkernel continues shrinking
until it finally becomes nothing, then it implodes and all its insides are
now outside. All kidding aside, the idea of the exokernel is one that I have
a really hard time accepting. The exokernel system consists of a very small
OS core which provides only the barest minimal set of functionality. This
minimal set of functionality includes allowing applications to allocate
resources and see what resources are available on the machine, and also a
few assorted services such as supplying a mapping between cache pages and
the disk blocks they are backing. Clients to the kernel itself are presented
with the lowest level abstractions of the actual hardware as possible - for
instance when talking to the kernel about disk usage the units used are true
disk blocks... certainly the kernel provides no concept of file. The paper
really kind of skimps a bit on detailed discussions of how the
implementation actually looked and doesn't (at least to me) make it clear
what was done in the "kernel" and what was left out. However the basic idea
comes across perfectly well which is that applications are left to deal with
what is almost bare hardware. The idea then is that the majority of services
normally provided by operating systems are offered in what are termed as
"libOSes". A libOS is a user mode library which provides some higher level
of abstraction to its clients of the raw hardware exposed from the true
kernel. Thus, the libOS'es become the operating system. The authors describe
a concrete set of work they did towards a full implementation of an
exokernel system. Xok is the true exokernel core, ExOS is the primary libOS
they create which provides something quite similar to the system interfaces
one would normally see on a Unix platform. One very compelling point about
exokernel systems is that the system interface is defined entirely by the
libOS, of which there can be any number on the system. Therefore there is a
certain "polymorphic" quality to the OS. A large part of the paper is spent
describing how to expose stable storage in an exokernel system. Apparently
the problem is quite difficult as the solution described, XN, is the 4th
iteration for the authors. The challenges arise from the fact that in
keeping with exokernel concept throughout the system the authors chose to
make the file system (of libFS) part of the libOS layer; therefore the
system in theory should support multiple file systems on top of the same
piece of disk real estate. This is an idea I have never heard of before and
certainly would seem to be quite ambitious to try to implement in any truly
successful way. The final part of the paper goes over performance results
from various benchmarks run on their Xos implementation compared with some
standard Unix implementation for X86 platforms such as FreeBSD. Not
suprisingly, the benchmarks look good. When you essentially don't have an OS
and can build a web server, or whatever application you will, directly on
the hardware you are going to see performance improvements. If I sound a bit
cynical it's because I really am; for various reasons I don't really see
this as a good idea. 1 - I was not really able to decipher a clear reasoning
from the paper on how this kind of system could even begin to offer true
security and protection; it seems that it would be very hard to achieve
these goals in an exokernel system. I do know that the paper addresses
protection specifically, but I suppose I don't really understand how that
protection is manifested in the implementation. 2 - It's fast in their
benchmarks, and they claim that they have done some testing to show it works
well on loaded systems, but it seems impossible to buy into the idea that
one poorly written application couldn't completely monopolize the system
resources. 3 - I will admit that this is a great idea for the most
performance sensitive applications, and that the the Cheetah web server
described is the meanest, baddest web server I've ever heard of, but yet the
investment in time and almost more importantly skill to correctly build an
application from such a primitive base seems likely to be prohibitive.
This archive was generated by hypermail 2.1.6 : Tue Jan 20 2004 - 23:20:17 PST