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

can prepare for it by saving any data that it needs
and bring itself to a stable state. For example, a
process may be asked to give up a page of memory
and it may not matter which page of memory it
de-allocates. Because the process is kept informed
of the resource de-allocation, the process may be
allowed to simply change a few pointers to reflect
the change, or it may be allowed to choose which
page of memory it gives up. It may also choose to
write that page of memory to disk to free-up the
memory requested by the kernel. In either case,
the process cooperates with the kernel, and by
doing so, the revocation of the resource is less
intrusive for the process.
Just like in a traditional operating system, a
process that is not cooperating with the kernel's
request to de-allocate a resource must, on occa-
sion, be forced to comply with the kernel's request.
When a secure-binding has to be broken by force,
it “simply breaks all existing secure bindings to
the resource and informs the Library OS” (Engler,
Kaashoek, & O'Toole, 1995).

efficient operating system. Furthermore, since a
LibOS is written with a specific user process in
mind, a LibOS does not have to be all-things to
all-processes as we stated was true of a traditional
operating system.A LibOS can be simple and more
specialized, primarily because “library operating
systems need not multiplex a resource among
competing applications with widely different
demands” (Engler, Kaashoek, & O'Toole, 1995).
So far as the LibOSs use standardized interfaces,
these LibOSs allow for applications to be easily
ported to different computing hardware. Because
the LibOSs are so specialized, one may wonder
if this leads to a lot of extra code in user space.
One may also wonder if some of this code is also
redundant. The Exokernel addresses this concern
by what the researchers call “shared libraries”.

Shared libraries

Not all of the user level libraries have to be spe-
cialized code that is written for a specific process.
Different processes can often reuse the same code
that is written for another process. Therefore,
the Exokernel allows processes to share code in
what it calls a shared library. By sharing code, the
amount of disk-space and memory-usage can be
significantly reduced. The disadvantage of sharing
code with a LibOS is what Douglas Wyatt calls
a “bootstrapping problem” (Wyatt, 1997). The
problem is that the code that is needed to load the
LibOS from disk into memory is actually found
in the LibOS itself (which cannot be accessed
until the LibOS is actually loaded into memory).
The solution to the bootstrapping issue will be
explained when we discuss the shared library
server (section 3.7).
Another of the key issues that Douglas Wyatt
has identified with a shared library system is what
he calls “symbol resolution” (Wyatt, 1997). The
issue arises from the fact that when a program is
run for the first time, it needs to know particular
memory addresses in order to run correctly. One
way to address this problem is to load a shared

management by user level library

Previously we stated, the Exokernel Operating
System's kernel is responsible for providing
protection of resources while the management of
those resources is left up to another entity. This
other entity is known as the “user level library
operating system”, or “LibOS” for short. This
LibOS lies outside the kernel where it is available
to user processes.
The LibOS can be thought of as being very
similar to a traditional operating system in that the
LibOS is the middle-man between the user pro-
cesses and the actual hardware. Like the traditional
operating system, the LibOS provides the abstrac-
tion that user processes interact with when they
want to communicate with the hardware. However,
unlike a traditional operating system, a LibOS
can be customized to fit the needs of the software
applications. This customization leads directly to
optimization, which in turn leads to a much more