The Flux OSKit: A Substrate for Kernel and Language Research

What kind of paper is this?

• New idea (a toolkit of components).
• Describes the system.
• Describes some uses of the system.

Goals

• Reuse pieces from lots of existing operating systems.
• Make it easy to build a specific operating system.

Toolkit Components

• Bootstrapping
  • Support Multiboot standard
  • Allows booting any kernel that adheres to the standard.
  • Wrap older kernels to be loaded by Multiboot.
  • Can load additional files (in addition to the kernel) at boot time.
  • Use boot modules for things like drivers, file systems, init, etc.
• Kernel support Library
  • Only library that is exclusively useful in kernel mode.
  • Architecture specific.
    • Makes an x86 usable in 32 bit mode.
    • Initialize segment tables.
  • Contains functions to manipulate the hardware.
  • Reserves all the physical memory.
  • Client OS can override anything in here (same as with anything else).
• Memory Management Library
  • List-based memory manager (LMM)
    • Allocate either physical or virtual memory.
    • User or kernel level code.
    • Handles different types of memory.
  • Address map manager (AMM)
    • Designed for kernel mode (although can be used in user mode).
    • Manage address spaces that do not map directly to physical or virtual memory.
• C library
  • C library that it not optimized and dependent as a regular C library.
  • Minimal functionality library.
    • No buffering in stdio.
    • No floating point.
    • No locales.
• Debugging
  • Serial support for Kgdb.
  • Malloc debug library.
• Device Drivers
  • Use existing Linux and BSD drivers.
  • Use encapsulation (glue layer) to make them all conform to same interface.
  • Allows drivers from different systems to coexist in the same kernel.
• Protocol Stacks
  • Use encapsulation to incorporate existing stack.
  • Take networking from BSD (mature stack).
  • Run with Linux driver (wider variety).
• File Systems
  • Also use encapsulation.
  • Export COM interfaces similar to VFS ops.

Design and Implementation

• Primary goal: ease of use.
• Builds and installs by itself (uses all its own includes, etc).
• Modularity
  • Need seprability in addition to modularity.
  • Reduce dependencies between modules.
  • Must be able to override individual functions.
  • Must be able to bind functionality dynamically.
  • End up with two degrees of granularity.
    • Function: libraries of individual functions that can be mixed and matched.
    • Component: big chunks that are fully functional (e.g., file systems, device drivers).
• Interfaces
  • Use COM as the interface definition language.
  • Use standard inheritance and extending to build different interfaces.
• Execution environment
  • Some code makes assumptions about synchronization (e.g., device drivers).
  • Each component implements a particular execution model.
  • Glue code can be used to change the execution model.
• Open Implementation
  • Expose implementation when necessary.
  • Export lower level funtions, so client OS's can customize them.
• Encapsulation
  • Assimilate simple code (or code that isn't expected to change over time).
  • Big chunks get encapsulated.
    • Define a COM interface for the module(s).
    • Implement glue code to make actual code adhere to COM interface.
    • If real code changes, all that has to be modified is the glue code.
    • Retain source code structure (i.e., directory structure) as well.
    • Use glue code to handle name conflicts (i.e., type declarations).
    • Use macros to define namespaces for different chunks.
    • Emulate environment assumptions in glue code (e.g., construct a curproc structure for a BSD device driver).

Example OSKit System

• This is really cool stuff!
• Build a kernel to run ttcp.
  • While this is cool -- does it really capture all the overhead?
  • It's not a full Client OS.
  • Performance penalty for OSKit.
  • Is the penalty worth it?
• Fluke OS
  • Motivated OSKit.
  • Over half of Fluke is OSKit.
• Standard ML
  • Port of Standard ML of New Jersey onto OSKit.
  • Summer project to build system.
• SR
  • Concurrent and parallel language.
  • About two weeks!
• Java OS
  • Kaffe + OSKit
  • One day for base system.
  • Three weeks for complete system.

Lessons Learned

• Standards are good (i.e., POSIX helped).
• Omitting process/thread abstraction was a benefit for language systems.
• Exposed hardware makes language systems easier to build.
• Can omit what you don't need and get a "small" system.
• Can take the best parts of existing systems.
• Interfaces are good.
• Release enginerring and packaging is important.
• Documentation is important (quel surprise).
• Glue code adds size and reduces speed.
• Spend a lot of time in allocation/deallocation.
• Exiting and OSKit application (i.e., a kernel) isn't clean.
• Need to expose as much of the hardware detail as possible (e.g., the interrupt stack).