about OS/161 | about System/161 | project news | publications | license | credits
download | guides and resources | documentation | for instructors | bugs | mailing lists

About OS/161

OS/161 is a teaching operating system, that is, a simplified system used for teaching undergraduate operating systems classes. It is BSD-like in feel and has more "reality" than most other teaching OSes; while it runs on a simulator it has the structure and design of a larger system.

There are two supported branches of OS/161: the 1.x branch, first launched in 2001, provides a uniprocessor kernel programming environment; and the 2.x branch, which debuted in 2009 and was finally fully released in 2015, moves into the multicore era by adding multiprocessor support and other more modern attributes. Both of these branches are actively maintained.

OS/161 includes both a kernel of conventional ("macrokernel") design and a simple userland, including a variety of test programs. It is written in C and uses (but does not itself include) gcc as its compiler. It includes support for only one architecture, but is structured as a portable system, with processor- and platform-dependent code segregated for maintainability.

The base OS/161 system provides low-level trap and interrupt code, device drivers, in-kernel threads, a baseline scheduler, and an extremely minimal virtual memory system. It also includes a simple skeleton file system and an emulator pass-through file system, with a VFS layer to allow using both at once.

Other things are not included and are to be implemented by the students as programming assignments. The basic sequence of these is:

1. Locks. OS/161 comes with interrupt handling (and in 2.x, spinlocks) and semaphores; the students implement sleep-locks and condition variables, and possibly also reader-writer locks or other synchronization tools, and use these to solve two or three problems of the dining-philosophers type. At schools where this material is part of a prior course this assignment is often skipped.
2. System calls. OS/161 comes with kernel ABI definitions, but no system call layer except for a minimal example (reboot, and in 2.x also __time); the students implement the basic set of file and process system calls and add the necessary support infrastructure to the kernel.
3. Virtual memory. The "dumbvm" shipped with OS/161 is only meant to be good enough for bootstrapping the system and doing the early assignments. It never reuses memory and cannot support large processes or malloc. The students write a proper VM system.
4. File system. The file system as shipped with OS/161 is limited and also uses one big lock (in 2.x) or has no locking at all (in 1.x). The students refit the file system with proper fine-grained locking and extend it to add features or remove limitations of the basic version. Or, alternatively, the students can be given solution code for this material and asked to implement file system journaling.
5. Something else. Many other things can be added on to OS/161 at this point. Students pick something suitable (neither ridiculously involved nor absurdly trivial) and implement it.

Solution-set code for these assignments is available to instructors.

Note that there is no network stack in the base OS/161. While we generally do not tackle networking in our OS class (as we have a separate networking class) there is network hardware and adding simple networking support to OS/161 is a viable assignment. Porting a real TCP/IP stack is probably not.

For more information on the assignment structure, see the SIGCSE paper.

David A. Holland, Ada T. Lim, and Margo I. Seltzer, A New Instructional Operating System. Proceedings of the 2002 ACM SIGCSE Conference on Computer Science Education, March 2002. PDF