Understanding OS/161: A Beginner’s Guide to the Teaching OS

What Is OS/161 and Why It Matters

OS/161 is a lightweight, educational operating system that many universities use to teach core OS concepts. Developed at the University of Michigan and later adopted by MIT, it runs on a simulated MIPS processor, making it easy to experiment without real hardware. By stripping away the complexity of production‑grade kernels, OS/161 lets students focus on system calls, process scheduling, virtual memory, and file‑system design—all within a manageable code base.

Key Design Goals Behind OS/161

The creators set three objectives in mind: simplicity, modularity, and portability. Simplicity means the entire kernel fits into a few thousand lines of C, so newcomers can read the whole thing without getting lost. Modularity is achieved through clearly defined subsystems—process management, threading, and device drivers each live in separate directories, encouraging a plug‑and‑play mindset. Finally, portability stems from its reliance on the sys161 simulator, which abstracts the underlying hardware and runs on any modern Unix‑like platform.

Core Components of the OS/161 Architecture

Even though the codebase is small, OS/161 mirrors the structure of full‑scale kernels. The main subsystems include:

• Process and Thread Management: Handles creation, termination, and scheduling of lightweight threads within a process.
• Memory Management: Implements a two‑level page table, demand paging, and a simple frame allocator.
• File System: Provides a minimalistic, Unix‑style file system with support for directories, inode allocation, and basic I/O.
• Device Drivers: Offers a skeleton driver for the console and a simulated network interface.
• System Call Interface: Exposes a set of calls (e.g., fork, execve, read) that student programs use to interact with the kernel.

Each module lives under the src tree, and the build system (based on make) lets you compile only the pieces you need for a particular assignment.

Getting Started: Setting Up Your Development Environment

Before you dive into code, you’ll need a Unix‑like host (Linux, macOS, or BSD) with the following tools installed:

• GCC (or Clang) for compiling C files.
• GNU Make to drive the build process.
• Git to clone the official OS/161 repository.
• QEMU (optional) if you prefer a graphical view of the simulated machine.

Clone the repository, run the provided configure script, and then build both the kernel and the sys161 simulator with a single make command. After a successful build, you’ll have two executables: os161 (the kernel image) and sys161 (the simulator).

Running Your First Program on OS/161

OS/161 ships with a tiny “hello world” user program written in C. To compile it, use the make target test, which links the program against the OS/161 system call library. Then launch the simulator:

sys161 os161 -e hello

The console should display “Hello, OS/161!” confirming that the system call interface works. From here, you can start modifying the source, adding new system calls, or tweaking the scheduler to see how your changes affect the running program.

Typical Coursework Built Around OS/161

Most operating‑systems courses structure their labs around incremental milestones. Early labs focus on getting comfortable with the build system and writing simple system calls. Later assignments might ask you to implement:

• A round‑robin scheduler that respects thread priorities.
• A copy‑on‑write fork implementation to reduce memory usage.
• A disk driver that interacts with a simulated block device.
• A rudimentary network stack capable of sending and receiving UDP packets.

Because the kernel is deliberately small, you can finish each lab in a few days, giving you time to reflect on design choices rather than wrestle with obscure bugs.

Debugging Tips for New OS/161 Developers

Debugging kernel code can feel intimidating, but OS/161 includes a built‑in debugger that integrates with gdb. Start the simulator with the -d flag, then attach gdb to the sys161 process. Breakpoints work just as they do for user‑space programs, allowing you to step through kernel functions, inspect registers, and watch page‑table entries change in real time.

Another handy trick is to sprinkle kprintf statements throughout the kernel. Unlike printf, kprintf writes directly to the console without relying on the partially built I/O subsystem, making it a safe way to trace execution during early development.

Where to Find Help and Community Resources

Although OS/161 is primarily an academic tool, a modest community surrounds it. The official GitHub repository hosts the latest source, issue tracker, and a set of sample solutions. University course pages often publish lab handouts and solution snippets, which can be useful reference points. If you run into a roadblock, a quick search of the os161 mailing list or Stack Overflow usually yields a helpful answer.

Frequently Asked Questions

Q: What programming language is OS/161 written in?

A: The kernel is almost entirely written in C, with a few assembly routines that handle low‑level context switching on the MIPS simulator.

Q: Do I need a real MIPS board to run OS/161?

A: No. The sys161 simulator emulates a MIPS CPU, so everything runs on a regular x86 or ARM host.

Q: Can I use OS/161 for research, not just coursework?

A: While it’s designed for teaching, its modular structure makes it a convenient sandbox for experimenting with new scheduling algorithms or memory‑management policies.

Q: How do I add a new system call?

A: Define the call in syscall.c, assign it a unique number in syscall.h, and implement the user‑space wrapper in the libc provided with OS/161. Rebuild the kernel, and the call becomes available to any program you compile against the OS/161 C library.