CSE 3320-002 Operating Systems project proposal
Andy Goth, Fall 2004

This semester I plan to design and implement an experimental operating system.
I say `experimental' because its primary purpose, to me, will be for playing
with experimental operating system algorithms and architectures.

The working title for this operating system is Manos, because it may eventually
incorporate some elements of the Plan 9 operating system, and because "Manos:
The Hands of Fate" is the only movie worse than "Plan 9 from Outer Space".
There are rumblings about another operating system of the same name, but I have
been unable to find anything more than vapor and subscription-only pages.

Initially, it will run under a host operating system, GNU/Linux, but eventually
I plan to make it bootable using grub, the GNU Grand Unified Bootloader.

Manos's most striking feature is its requirement that all system programs and
applications must be written in the Tcl language.  However, library functions
may be written in Tcl or C or some combination thereof.  These may be
statically linked into the kernel image or dynamically inserted by privileged
processes.

Both Manos's process and security models derive from its Tcl-only requirement.
Each process is implemented as one or more Tcl interpreters.  Each thread in a
multithreaded process also has at least one interpreter.  Each interpreter is
only given access to commands (library functions) and channels (files and
devices) that its process has a right to access.  If a program is not allowed
to perform some function, the commands implementing it simply are not made
available to it--- it cannot call them.  The parent interpreter is responsible
for providing commands to the child interpreter, and the kernel serves as the
parent of the init/login interpeter(s) which in turn are the parents of the
user programs.  The login interpreter gives the user's shell interpreter access
to everything that user should be able to access.

Since everything's written in Tcl and the Tcl runtime library internally does
all permission checking as a side effect of command lookup, there is no need
for Manos to utilize the CPU's monitor/user modes.  Everything will be run in
monitor mode, thereby minimizing the overhead of syscalls.  At the C level,
syscalls are ordinary function calls.  (The hosted version of Manos, of course,
will only be able to emulate being in monitor mode--- it will in fact be a user
process with limited capabilities.)

At least for the first versions of Manos, all data will be stored in a Metakit
database serving as a filesystem.  The code actually implementing Metakit will
be stored in the kernel as a statically-linked library.  All filesystem access
in Tcl scripts and well-behaved Tcl extensions is performed through the Tcl VFS
layer, which can redirect all reads and writes to the Metakit implementation.
Future versions of Manos may allow additional filesystem types implemented in C
or Tcl script, depending on the usability of the tclvfs project.  

Each process can have its own view of the filesystem, because the configuration
of the VFS is per-interpreter.  But actually making this work properly again
depends on tclvfs.  This feature in particular makes Manos similar to Plan 9.

Manos, at least in its bootable incarnation, will probably have only minimal
hardware support.  It'll run on systems with i486 processors (for CMPXCHG), VGA
emulation, i8042-compatible keyboard controllers, and perhaps floppy disk
drives.  Support for additional hardware may be loadable at runtime by
inserting new functions into the kernel and exporting them for general use in
the form of Tcl commands.  If there is no floppy support, then the initial
filesystem image will simply be part of the kernel image and loaded from disk
into memory by grub, then mounted by bootstrap code embedded in the kernel.

Scheduling, memory management, and disk I/O elevators may be tunable by a
suitably-privileged process dynamically replacing the algorithms with new Tcl
scripts.  This is liable to be slow, but it would be useful for experimenting
and testing with realistic loads.

Event handling is performed using the existing Tcl event loop and the fileevent
command.  Tcl represents files and devices as channels; I plan to also make
timers and other pseudo-devices available using this mechanism.  A channel is
said to be readable or writable if performing a gets or puts on the channel
will not block the program (if the channel has been marked as non-blocking).
But gets and puts don't always make sense for all possible devices, as many are
not stream-oriented, for instance timers.  Such devices are still marked as
readable and writable but are accessed through special device-specific Tcl
commands.

As I said, I'm writing this to give myself a platform for experimentation.
Possible future projects include:

- Enhanced terminal system
- Extended virtual filesystems
- Support for more hardware
- Networking and network filesystems
- Scheduler algorithms
- I/O elevator algorithms
- Memory management algorithms
- Checkpointing
- Single-level store