Title
The Flux OSKit: A Substrate for Kernel and Language Research

Author
Ford, Back, Benson, Lepreau, Lin, Shivers

Location
SOSP

Date
1997

Writing the same essential procedures which all OS's take for granted,
like bootstrap code and initializing some hardware structures is
"tedious, costly, and often impractical except for large projects."
OSKit provides a collection of well-documented components to enable
research into more interesting areas like memory management and
scheduling.  To make OSKit more easily portable to new devices, much
code is easily imported from Linux and the BSDs by wrapping it in
"glue" code.  At least, this is what the authors say.  They argue
that, although "mechanism is policy", the OSKit does not define any
"core" functionality, but merely provides a suite of components from
which real OS's can be built.  They would argue that these components
are not policy in themselves.

Currently, three research OS's are based on OSKit: Fluke (at Utah),
Standard ML (at MIT) and a JavaVM (also at Utah).  The "client OS"
need only provide a main function in the standard C style.  They
include a "Hello World" OS.

A nice side-development is the Multiboot standard, which gives the
ability to load additional modules along with the kernel itself.  The
addresses of where the modules have been put in memory is given to the
kernel.

OSKit includes two distinct Memory Management libraries:
1) list-based memory manager (LMM) which provides primitives and
support for managing multiple "types" of memory in pools.
2) address map manager (AMM) manages address spaces which do not
necessarily map into physical or virtual space.

Other nice items are:
- minimal C library
- serial line debugging with GDB
- encapsulated TCP/IP stack, with code taken from Linux and BSD.
- File system interface built with COM instead of with VFS.  A COM
interface is an opaque structure whose actual size and content is
unknown to the client, except that its first member is a pointer to a
table of functions (similar to C++ virtual function table).
- dynamic binding to device drivers
- OS components are modular and separable, meaning that their a few
(or no) dependencies, and that there is a clear API.

Drawbacks:
- COM and glue code require copying occasionally (as seen in TCP
experiments).  Profiling revealed that this was a problem.
- Components are not thread or multiprocessor safe and big lock is
needed when using them.  
Flux OSKit

	This paper details a toolkit for quickly constructing basic operating
system functionality.  The motivation for the paper is based on the
observation that it is needlessly difficult to get the basic components of
an operating system functional to the point that useful operating systems
research can be conducted.  Rather than focusing on a versatile,
multi-functional, highly tuned operating systems, these researchers have
designed instead towards the goal of not only creating components but
entirely separable pieces.  As a result, the core code is very simple but
extremely portable.  For example, with some "glue" code, the researchers
were successfully able to meld linux network device drivers with FreeBSD
protocol stacks.  Also, the OSKit attempts to provide basic debugging
support for their operating system, another vital tool often difficult to
implement in such environments.  Finally, while each separate component of
the system (memory management, protocol stacks, file systems, etc.) presents
a unified interface to other components, entities desiring to take advantage
of low-level details of the component can optionally do so, though they do
not have to.
	I thought this paper was, if nothing else, very well motivated.  They did a
good job of presenting a rationale for embarking on their project, and
moreover they follow through with it with their examples of ML/OS, SR, and
Java/PC (the Fluke OS was not as compelling an example since it was their
original intention to build such an OS anyway, though the modularity of
Fluke OS is indeed impressive).  Moreover, I was extremely grateful to have
a final "deficiencies" section of their paper.  I give the authors a good
deal of credit for being forthcoming about the problems they have/had in an
otherwise very successful project.  I was dubious of their ability to create
a fast, sleek operating system with this method, but the authors were
careful to say that this kit is aimed at research goals only, and I believe
they accomplish their tasks.  A consequence of this may be, however, that
conducting tests heavily dependent on high performance may prove difficult
on this system.  In this sense, among others, Flux is not a universal salve.
As the paper also notes, for instance, the memory allocation is still a
problem, one which it may not be easy to solve.  Memory allocation varies so
widely that it may be difficult to construct a universal memory allocator.
It would seem that other very central operating systems components may
eventually suffer from the same ailments, namely the threading and
scheduling systems.  It seems to me that providing a universal interfaces
for such a design-dependent system may be a pipe dream, and moreover we may
find that the ways in which Flux was designed to be universal will soon
become outdated paradigms of design.  Still, the idea is a good one and they
seem to have had unanticipated success with it.