Back to index
The Flux OSKit: A Substrate for Kernel and Language Research
Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, and Olin
Shivers
One-line summary:
The Flux OSKit provides clean, well separated and document library-like
components that provide core functionality of operating systems; the
separation allows OS developers to easily incorporate or override the
functionality of individual components as desired, yielding rapid OS
development time at the price of performance.
Overview/Main Points
- Main concern of this paper: doing OS research is hard, because
building OS's involves writing large amounts of intricate, messy
code to deal with hardware. Most OS's have a large amount of
code in common; the OSKit provides library-like code components
that implement much of this common functionality, and maintains a
clean enough module separation that individual modules that be
used, excluded, or overriden at will.
- Secondary concerns: this paper uses the "level of
indirection" solution of computer science. All modules are
completely abstracted away through glue code (both for upcalls
and downcalls - the modules are surrounded by glue instead of
having just a layer of glue on top). Benefits:
- It is easy to incorporate and use components: e.g. don't
need to know hardware-specific details of ether cards
in order to incorporate/use ethernet drivers
- It is easy for components to communicate with each
other - the COM interface standard is used, meaning
there is a well-known way for components to find out
each other's basic and extended functionality
- By abstracting away through glue encapsulation, it is
possible to pick and choose among the myriad of
operating systems out there and bring the best features
of each into the OSKit. Linux device drivers and BSD
networking code are all part of OSKit, suitably
encapsulated in glue code.
- Performance? They made little attempt to optimize OSKit for
performance - flexibility and rapid development was their goal,
not blazing speed. This is a MAJOR difference between OSKit and
other OS research platforms like SPIN, Vino, Exokernel, ...
Relevance
Bottom line: OSKit seems to provide what the developers intended - very
rapid and painless OS development time, but with plenty of opportunity for
specialization. Steve says "two thumbs up with a circle".
Concerns
:
- OSKit attempts to minimize cross-module dependencies by
abstracting away functionality. Of course, by doing
so, you lose the ability to take advantage of features
not present in the abstraction. Counter-argument: if
you want to do that, the clean separation allows you to
specialize the component that you're interested in.
Question: are there specializations that I may be
interested in that would force me to change large
amounts of an OS, not just isolated modules?
- Dynamic binding: devices are represented by tables of
functions, which can be swapped around at run-time.
How do device-driver users know the semantics of the
functions? Are all possible sets of function tables
for a class of devices assumed to have identical
semantics, but different implementations?
- Performance: sucks now because of all of the extra
glue, and some extra data copies incurred because of
the glue. Question: could OSKit be the right approach
in the long term, when relative CPU cycles are
abundant and the glue stops being the overhead? I.e,
is OSKit the right architecture for an "I/O
processing" machine?
- How much of the OSKit structure is necessarily x86
dependant? (Impossible to tell from paper.)
Back to index