The Flux OSKit: A Substrate for Kernel and Language Research

What kind of paper is this?

• This is almost a project report paper.
• The encapsulation techniques are, perhaps, the real intellectual research constribution.
• The artifact is also an enormous contribution to the field.

The Story

• Building operating systems is hard. The operating system is a large complex beast and in any typical research project, only a few parts of it are of real interest. Yet, building a new system means dealing with all the other parts as well. Can we make this easier? The answer is yes! We can build a set of components with well-defined interfaces that can be combined in myriad ways. By wrapping legacy code, huge amounts of kernel code from disparate systems can be made available and components from these different systems can be combined ininteresting ways.

The big idea

• Make it easier to build operating systems by providing a collection of OS components.
• Also, make it easy to incorporate existing mature code into the toolkit.
• Example components
  • Boostrapping code
  • Minimal posix
  • Physical memory management
  • Protocol stacks
  • File systems
• In use at: local = Fluke microkernel; MLos; network computer

Key Components

• Bootstraping: adopts multi-book standard -- allows for loading of boot modules (things that get loaded into a chunk of memory).
• Kernel support library: architecture specific, example x86 functionality: set up 32-bit execution, initialize segmentation and page tables, etc.
• Memory Management library: manage allocation of different types of memory as well as manage address spaces.
• Minimal C library: designed to minimize dependencies rather than maximize performance.
• Debugging support: serial line stub and memory allocation debug library.
• Device driver support: provides wrappers to make it easy to import existing drivers.
• Protocol stacks: also provided by encapsulation -- what is cool is that they are a combinatoin of Linux device drivers and a BSD stack!
• File Systems: used wrapper to get NetBSD file system.

Design and Implementation

• Independent of any code on your system
• Host machine just requires a dev environment (compiler, linker, etc)
• Build/Install creates a bunch of libraries (instead of a collection of C files)
• Not just modular, but separable. Techniques to get this: overridable functions, basic OO over-riding (i.e., get a pointer to an object and invoke methods on it).
• Hmmm -- adopted COM interfaces (Component Object Model).
• Much of the design and interface design is all in the support of separability.
• Code is imported from other systems either "as is" -- which means maintaining it, or via encapsulation, which case it only requires update when its interfaces change.
• Code is incorporated in its original source tree form.
• Types resolved through glue code
• Emulate assumed structures, e.g., curproc, by having glue code set them.

Evaluation

• I consider the case studies to be the eval.
• The language-based OS projects are pretty amazing in how quickly students were able to construct a language-specific OS.
• The network computer example is the kind of thing that we want to be able to do with Velosity