The Exokernel Operating System and Active Networks - Advanced Operating Systems and Kernel Applications - page 146

still retaining the role of the protector of resources.
Because this form of interprocess communication
is immediate, the Exokernel enjoys a processing
speed-up.

ment of the exception is handled in user space,
by the Library OS.

disk i/o

exceptions and interrupts Disk I/O - reading and writing to memory loca-

tions - is accomplished asynchronously in order
to minimize the involvement of the kernel. It is
the Exokernel's “exodisk” that handles all read
and write requests. When an application needs
access to memory, the exodisk simply passes
the request off to the disk driver. After the read
or write request is made, the calling application
immediately regains control. Since the request
is asynchronous, the calling application has the
option of waiting for the memory request to
complete, or it can continue without waiting for
a completion response from the exodisk.
When the memory read or write request com-
pletes, the Exokernel is notified of this event by
the requesting application. However, very little
more is required of the Exokernel. The Exokernel
retains its minimal involvement by helping pass
the disk I/O request to the exodisk and allowing all
of the details of the disk I/O request to be handled
by user-level code found in the Library OS.

An exception or interrupt requires a traditional
operating system to save register data to a more
secure location in order to protect and preserve
its current state of operation. The kernel also has
to respond to the exception, which requires the
exception to be decoded by the kernel and then
specific code needs to be executed to handle the
issue raised by the exception. Once the exception
has been dealt with, the kernel has to restore the
registers to their pre-exception state and start run-
ning the original program from a point where the
program counter was just prior to the exception.
An Exokernel, on the other hand, handles
exceptions and interrupts by getting less in-
volved. For example, exceptions and interrupts
that arise from hardware are handled directly by
the applications themselves. The Exokernel only
gets involved enough to save important register
information to what Engler calls an agreed upon,
user accessible, “save area” (Engler, 1998). The
Exokernel saves the register data, loads the excep-
tion, then starts to execute at the memory address
of the code that has been written specifically to
handle the exception. This special code is under-
stood to be located in what we have been calling
the user level library.
The kernel's job is done as soon as the Library
OS takes over the handling of the exception. As
soon as the exception is handled, the original
register data is written back to the registers
from where they were stored in user-accessible
memory. The normal program execution con-
tinues from where it left off just prior to the
exception without any further assistance from
the kernel. Therefore, the kernel gets involved
just enough to provide protection of the current
state of the registers, whereas the actual manage-

downloading code into the Kernel

Since one of the goals of the Exokernel is to be
optimally efficient, one of the ways the Exokernel
attempts this is by downloading code into the
kernel. Downloading code into the kernel is not
unique to the Exokernel. It is a technique that
other operating systems have used as a way to
minimize the cost of a context switch.
One of the main advantages of downloading
code into the kernel is that it eliminates the need
for code to make what are called “kernel cross-
ings”, which can require an expensive context
switch (Engler, Kaashoek, & O'Toole, 1995).
Context switches are undesirable because they
can severely impede an application's execution
speed. By eliminating kernel crossings, context