Jamison Collins (
Tue, 6 Jun 2000 00:51:16 -0700 (PDT)


The goal of SPIN is to provide an extensible operating
system. A previous attempt at
achieving this is by structuring an OS in the form of
a microkernel. However, communication
costs are very high in a microkernel, which acts as an
impediment as well as a motivation
for exploring the type of structure impelemented by

Protection is still enforced with SPIN because the
kernel, as well as all extensions, must
be written in Modula 3. This typesafe language
enables safe extensions to the OS because
the language characteristics enforce sufficient
protection. One advantage of using a typesafe
language for OS extensions is that protection can be
enforced with capabilities which are
simply pointers, rather than requiring them to be
further separated from code which makes
use of them. Extensions are achieved in terms of
events and handlers. A handler is written
for some event, and then registers itself to be
notified upon the occurence of the event
in question.

The goal of this work is to improve overall
performance, and the results section demonstrate
that that is achieved. On example that is given is an
application which serves up video
streams. The SPIN kernel requires approximately half
the cpu power that the vanilla
approach does.

This is very interesting work. As architecture
research has started to move towards dynamic
code modification to specialize it for the particular
processor, it is interesting to sees
OSes moving towards dynamic OS reconfiguration for the
specific applications which are being
used. It is also surprising to see that an OS written
in a garbage collecting language
still achieves good performance.


The Goal of the Exokernel is to transfer
responsibilities typically located in the kernel
into the application space. An typical OS is required
to provide a high level abstraction
to resources in order to be as generally useful to as
wide of a range of applications as
possible. However, this results in much lower
performance than could be achieved.

The kernel is written as small as possible, only
exporting the essential low level resource
control primitives. On top of this runs the library
OS, which are application level programs
that manage the resources exported from the kernel.
In doing so, then, resource protection
(provided by the true kernel) is separated from
resource management(provided by the
library OS). A necessary concept for this structure
of OS is that of secure bindings. As
mentioned in the paper, network connections have a
complex semantics to properly enforce
protection. However, this difficulty is primarily on
the bind time. Thus, a complex
bind time access check may be necessary, but each use
of the resource may require only
simple access checks, which the OS may not fully
understand even the access checks that
are being performed(as was done in ****).

Very much improved performance was achieved through
structuring the OS in this manner. This
demonstrates that reducing the number and cost of
kernel crossings, as well as allowing
applications to specialize resource allocation, are
goals that should be strived for in
future OSes.

This paper seems to provide a way in which the goals
of microkernels could be achieved,
yet performance could be maintained. Obviously, this
approach is not identical, but both
do result in small kernels which are much easier to
verify the correctness of. Similar to
the last paper, I find approaches such as these to be
very interesting and seeming to the the
'correct' approach for future work.

I have often wondered... what if we discovered
that we were threatened... by an outer power,
from outer space... from another planet?
Wouldn't we all of a sudden find that we
didn't have any differences between us at all?
That we were all human beings?

Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!