The Fluke Operating System Version 0.5 (Kernel Source Release) February 24, 1999 I. Intro: This release, arbitrarily labeled 0.5, is by no means a complete release, you cannot take the source included and build anything useful. The intent of this release is to give a feel for the principles described in the OSDI'99 paper ``Interface and Execution Models in the Fluke Kernel.'' A complete release of the Fluke Operating System is planned for March or April of 1999. That release will include everything including instructions on how to build a workable system. II. What it has: Two subdirectories are included, "fluke" which contains all the public header files, and "kernel" which has the bulk of the kernel source. "flukeref.ps" is the Fluke API reference manual, long on detail but short on rationale. It covers the syscall API pretty completely but lacks coverage of the "Common Protocols" and the security enhancements. III. What it is missing: Everything that isn't the kernel. Also, since the Fluke kernel uses the OSKit extensively, there are a number of missing (mostly low level) components that come from it; for example, the page table and TLB management. However, the source in this release is compatible with the 0.97 release of the OSKit so you can always go out and grab that for those missing pieces. Finally, since the "kserver" ("root" nester for the interposable IPC-based Fluke interfaces) component of the kernel runs in user-mode, it shares much library code with other nesters and applications in Fluke. That library code is not part of this release. In particular, the bulk of the code for handling the higher-level memory abstraction (the "mempool" interface) and the memory-based filesystem are not included. Again, these will be available when the full release comes out. IV. Points of Interest: fluke/ Contains files describing the machine-independent portions of the extractable state for all Fluke kernel objects. The complete state for most objects is here. Look here to get a sense of the size and nature of the state which is exported. fluke/cp/ Includes Corba IDL files describing the Fluke "Common Protocols" (i.e., the interposable IPC-based interfaces). fluke/x86/ Files describing the machine-dependent state associated with the Fluke objects. These files also contain the inline-assembly stubs for invoking the various operations on the objects. These invocations are MD since parameters are passed in machine registers. Here you will get a sense of the width of the syscall API. kernel/kserver/ The "root" nester for the IPC interfaces. This is a user-mode server which shares the kernel address space; i.e. the service threads are user-mode threads which make standard trapping syscalls to the kernel. Most of the code in this directory is glue to standard Fluke libraries which provide the bulk of the services. kernel/sys_* "Entry layer" handling of the trap-based Fluke system calls. Primarily, these deal with looking up the objects involved. Here you will see examples of restarting syscalls as well as state tweaking for multi-stage calls. kernel/s_* The guts of kernel object manipulation. The "s_" prefix indicates that these are related to the handling of the supervisor portion of the object (as opposed to the user-level portion of the object mapped into the user AS). Look here for issues related to object creation, destruction and state extraction. kernel/x86/*_md.* x86 specific code for various functions such as trap and interrupt handling. Of particular note, look at ipc_md.c for the bulk of the IPC-path implementation that is used. kernel/x86/kmodule/ Special short-circuiting code used when the kserver is configured to run in supervisor mode. kernel/x86/nonblocking/ Contains the trap and context switch code for the interrupt execution model implementation. The latter deals with the architectural bias the x86 has toward the process model. kernel/x86/opt_*/ Code for "optimized" implementations of various kernel objects. Optimized handling of objects means implementation of kernel functionality in user mode, complete with the requisite rollback handling to preserve the atomicity properties of the API in the face of arbitrary preemption. This is one of those "you are not expected to understand this" sections of the code. Code in these directories is only compiled in if the appropriate CONFIG_OPT_* option is specified. V. Interesting configuration options: CONFIG_KPREEMPT: Code related to full kernel preemptability. CONFIG_EPREEMPT: Code related to partial ("explicit") preemptability. CONFIG_NONBLOCKING: The "interrupt execution model" configuration. The significant differences here are in the various csw* files. CONFIG_SMP: Multiprocessor support. FLASK: Code related to the "security-enhanced" Fluke system. This code add mandatory access control checks on kernel operations and implements the framework for interfacing these enforcement checks with an external security policy provider. VI. Dirty Laundry Everywhere you look. In particular, note the depravity that occurs in the name of debugging (DEBUG option): interfaces which are not virtualizable, state which is not exported, code which is not portable, and a sense of coherence that is totally lacking. There is a hack hierarchical stride scheduling implementation (STRIDE_SCHED/HIER_SCHED) which is standing in for the incomplete CPU inheritance implementation (USER_SCHED). The objects we call "spaces" in our papers are actually called "tasks" in the source (Mach heritage, sorry). We haven't made the change in our source yet. There is a fair amount of deprecated code in the release. Reading the "XXX" comments is occasionally enlightening and always a hoot. Fluke Team Flux Research Group Department of Computer Science University of Utah http://www.cs.utah.edu/projects/flux/