The Flux OSKit: A Substrate for Kernel and Language Research
Ford, Back, Benson, lepreau, Lin, Shivers (1997)
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).