OS/161: A New Instructional Operating System for Teaching Operating Systems Courses, Papers of Operating Systems

Download OS/161: A New Instructional Operating System for Teaching Operating Systems Courses and more Papers Operating Systems in PDF only on Docsity! A New Instructional Operating System David A. Holland, Ada T. Lim,1 and Margo I. Seltzer Harvard University Cambridge, MA 02138 {dholland,ada,margo}@eecs.harvard.edu Abstract This paper presents a new instructional operating sys- tem, OS/161, and simulated execution environment, System/161, for use in teaching an introductory under- graduate operating systems course. We describe the new system, the assignments used in our course, and our experience teaching using the new system. 1 Introduction Traditionally, undergraduate classes in operating sys- tems are taught using special-purpose instructional OSes. These systems are meant to be simple and easily comprehensible; they have pieces intentionally left out as exercises for students. Several instructional OSes of various types have been written. They seem to have a working lifetime of around ten years and then become dated, due both to changes in the OS community and to changing expectations and prior knowledge bases of students. We present a new instructional OS, called OS/161, and accompanying platform, called System/161. Our goals in its development were to (1) provide a realistic exe- cution environment; (2) facilitate debugging; (3) retain the simplicity and assignment-oriented structure neces- sary for course use; (4) help to familiarize students with the structure and layout of real OSes; (5) have the com- pleted OS at the end of the course be capable of running real, if small-scale, user applications; and (6) provide a cleanly written and robust code base. In the remainder of this paper, we discuss other teach- 1Also University of New South Wales. ing OSes and how they relate to OS/161, along with an outline of why we do not believe in using produc- tion OSes for teaching; then we provide an overview of OS/161 and System/161 from an instructional perspec- tive. Following that, we discuss our course structure and assignments, and our experience teaching OS/161 this past year (2001). Finally, we conclude with an analysis of the extent to which we met our goals. 2 Other operating systems The last new full-scale instructional OS was Nachos [1], which appeared circa 1993. Nachos has an unconven- tional architecture: the operating system kernel and a machine simulator are compiled into a single executable, which then runs as an ordinary process on some “host” operating system. User-level processes run in Nachos are run in the machine simulator, but the Nachos ker- nel runs on the host system’s native hardware. We refer to this design as “mixed mode”. In some ways it is quite clever: it means the Nachos ker- nel can be run in a standard debugger. It also means Nachos does not need to include its own implementa- tions of standard C functions, such as printf or strcpy, because the Nachos kernel is linked to the host OS’s standard C library. There are, however, some disadvantages to mixed mode. The machine simulator is for a fixed processor type, a MIPS r2000 running in little-endian mode. The host machine may be anything, which today means that it is not a MIPS r2000. It might not even be little-endian. This means that, depending on the choice of host plat- form, data sizes and representations may not be the same in the Nachos kernel and in Nachos user-level pro- grams. This causes a great deal of confusion and op- portunity for mysterious and unrealistic bugs. Further- more, because structure sizes may not be preserved, it is difficult to create a fully functional system call interface. Nachos has some additional related drawbacks: first, because the kernel does not appear in the simulated ma- chine’s RAM, it is not limited by memory constraints. This means that the size of kernel data structures does not significantly affect system performance, which makes the size/space tradeoffs for many design decisions unrealistic. And second, perhaps worst of all, all inter- facing to the machine simulator and simulated hardware devices takes place via C++ objects. This means stu- dents receive no exposure to the way real hardware is actually accessed, even though that is a significant as- pect of kernel programming. For teaching, a certain amount of realism is desirable. Too much realism, however, becomes both too compli- cated and, sometimes, realistically painful. We take the position that methods and mechanisms should be real- istic, but details should be simplified: the System/161 hardware is accessed the way real hardware is, but the devices themselves are simple and easy to work with. By contrast, handling real devices, especially on i386 plat- forms, involves a large collection of complicated device drivers, making a system large and less readily compre- hensible than it might otherwise be. Recently Nachos has been modified to run as a native kernel on top of SimOS [4]. This alleviates many of the problems with mixed mode described above. SimOS is a MIPS machine simulator similar to System/161; however, SimOS simulates real hardware and can in fact support real OSes like Irix, and the modified Nachos must accomodate this. Minix [5] is often used as an instructional OS. It can be run on real hardware, or on an i386 simulator such as Bochs [3]. It thus offers a substantial, perhaps excessive, degree of realism. Another new teaching OS is Topsy [2], which runs na- tively on MIPS simulators such as SimOS. However, it includes no native support for either paged virtual mem- ory or file system operations; it does not appear to be intended to illustrate the design and implementation of a complete system but rather to offer a platform for teaching concurrency and hardware manipulation. Other past instructional OSes that appear to be more or less obsolete include Xinu, from Purdue circa 1984, and TOY, developed in 1973. The ultimate in realism is to use a real production OS. This has drawbacks, however, beyond the issue of de- vice drivers: real OSes are immensely large and com- plicated, and are full of complexities and constructs for coping with real-world issues that have little instruc- tional value. Furthermore, real OSes are already fully functional, so students do not get to design or imple- ment major subsystems or even minor interesting parts. Finally, production OSes are usually too slow for simu- lators; running them on bare hardware makes debugging much more difficult and requires making hardware avail- able to students (often problematic). We feel that for these reasons, introductory OS classes involving kernel programming at all should avoid production OSes. 3 System/161 We came to the conclusion that computers are now fast enough that, even on the chronically overloaded under- graduate computer facility, it is practical to use a com- pletely simulated platform for teaching the operating systems class. We thus created a simulated hardware platform, Sys- tem/161. System/161 is extremely simple: the first and foremost design goal was to provide the necessary functionality without complicating the operating sys- tems running on it. Thus, it has a straightforward bus architecture, into which simulated devices, supporting disks, serial ports, timer/clock, and random generation, can be inserted. These devices are accessed via reg- isters in the same way real devices would be. (There is, however, no DMA; instead some of the devices have memory-mapped transfer buffers.) The devices are min- imalistic: even the most complex one has only six regis- ters. The explicit intent was that an experienced kernel programmer would be able to write a complete set of device drivers in an afternoon. System/161 also contains a complete integer MIPS r2000 processor simulation running in big-endian mode. The code is structured to support multiple processor types. Support for several other processors has been proposed and/or begun, but not completed. Floating- point support is not planned. System/161 is written in portable C; it was developed under NetBSD on i386 hardware and used by students under Digital Unix on Alpha hardware. It consists of approximately 9,000 lines of code. On a 550MHz Pentium-III, the most recent version manages a little over 3MHz running cpu-intensive tasks. (This could un- doubtedly be improved.) While not ideal, such perfor- mance is acceptable, as OS code is rarely cpu-intensive. Perhaps the most significant feature of System/161, however, is the debugging support. System/161 con- tains its own remote gdb hooks, so any kernel loaded into System/161 can be debugged with gdb without needing support of any kind from that kernel. Even bet- ter, the debugging is completely transparent and does not affect the simulation’s timing. It is thus possible to trace right into the context switch, for instance, or to tackle timing-related problems in the debugger. By contrast, remote gdb to a real kernel running on real hardware requires placing the debugging hooks within the kernel itself. This unavoidably complicates the ker- nel and affects its operation; furthermore, it is generally