Teaching Operating Systems with Projects Stephen Taylor Worcester Polytechnic Institute Worcester, MA 01609
[email protected]
1 Introduction
They've worked on short projects intended to be nished in a week or two. There are advantages and disadvantages to each approach. Larger projects give students more of a sense of achievement, but students with less ability or fewer organizational skills can be left behind. Larger projects usually elicit more overall e ort from the best students. Smaller projects can have a higher concepts/to/code ratio, and since more of them can be assigned, the opportunity exists to address a variety of di erent areas. Here are some of the projects I have used, and my assessments of how each worked.
I have now taught operating systems a dozen times, and I use programming projects to motivate and involve my students in the course. Operating Systems is a systems course, and should give students An introduction to some of the models and theory used in scheduling, deadlock, paging. An overall view of how the individual pieces that make up an operating system are integrated. A sense of some of the resources and abstractions provided by the OS to applications programmers. A feel for handling concurrency. The teacher can introduce, but a feel, a sense, or a view must be created by the students themselves. Programming projects are among the most e ective ways of involving students in building their own abstractions. They require detail, but they also reward overview and planning. The content and nature of the projects helps determine what models students form. Projects can be of various sizes. Students have developed big chunks of an OS; they've done other systems-programming projects.
2 Toy Operating Systems In di erent courses, students built PC operating systems in two di erent environments, a 32-bit protected-mode time-sharing system, and a 16-bit real-mode non-preemptive multitasking system built on the PC BIOS. Students like using the PC because it is a real system environment, even if the student software is toy-strength.
2.1 32-bit PC OS
First year grad students implemented a simple protected mode kernel for the IBM PC. I provided enough initialization code to get the
1
2.2 BIOS-Based PC OS
PC into protected mode, and C sources for a user-mode thread package. The programming environment was Delorie's [1] port of gas/gcc, the Gnu compiler for the 386. Areas the project touched on included interrupt routines for clock and keyboard, process startup, a simple CRT window package, memory allocation and paging. Areas the project didn't touch on were les and networks. This was not a problem; the material was covered in lectures and additional reading. It would have been dicult to also build robust low-level disk routines in the course of a single term. However, one alternative to doing so is the BIOS-based OS discussed below.
Students built a BIOS-based multi-programming system with les. The group comprised 65 juniors and seniors, working in the second term of a two-term OS course series. The syllabus covered internal OS le structures, client-server architectures, and `largeproject' planning and documentation. Because we were operating in the 16-bit PC environment, tools included all the standard PC development tools, including: Microsoft Quick-C, Microsoft C, and Borland C, C++. Most students already owned PCs and C compilers, and the campus computing center also had PCs and software. I provided: a tiny thread package written in C and MASM, which supported thread-creation, semaphores, and context-switch. include les for DOS data structures assembly code samples for some BIOS functions, including non-blocking disk input DOS i/o was available, so C libraries all worked, with possible thread-safety problems, until student code began to interfere. The project was divided into independently graded phases; after each phase was due, I provided a minimal implementation of those features of the phase which later phases would need. The separate phases included: messagepassing routines; memory manager thread; window manager; elevator algorithm for disk i/o; DOS le read routines; DOS directory display routines; and DOS le lookup routines.
Outcomes The 32-bit protected mode project covered a large range of concurrency models. In particular, students learned to deal with interrupt routines and context switch routines; these understandings should generalize to other contexts as well. The students were engaged by the project, and showed it by the e ort they expended, 20-25 hours a week, too much work for an introductory course. A protected-mode debugger would have been helpful. A related problem is that the tools they were developing were for the most part already available to them in their current environment, but in more nished form. The main problem turned out to be documentation. I distributed handouts documenting features every week, but didn't always predict correctly where the problems would be. The students learned a lot about synchronization and scheduling, but most of their e ort went into discovering the PC. Their mastery of the material was exciting, but more documentation and a more appropriate programming environment was needed.
Outcomes
The students were excited by their achievements. Almost every student produced a windowed, multi-threaded environment into which a C program could be linked to read 2
les using only the student's own code, my assembly stubs, and the PC BIOS. Every student produced seven to twenty pages of design documents, explaining how they intended to implement each phase of the project. Students nished with a rm grasp of les as data structures on disk, an idea of the design tradeo s in various le structures, and experience with interprocess communication, micro-kernel design, and software design management of a mid-size project. The BIOS insulates programs from interrupts, as well as other details of the hardware, and the mechanisms it provides for dealing with concurrency lack the simplicity and elegance of the interrupt paradigm. Only a few students became involved in the BIOS interface, and most of those restricted themselves to using BIOS calls I had not provided interfaces for. I will nd a way to incorporate interrupt handling next time this project is used, perhaps by providing student-modi able lower-level device routines for the keyboard.
and the intentions are documented in various papers and technical reports. I assigned this project to a group of graduate students. They had three weeks to complete the project. Three of the group of twenty succeeded in the port; one of these said he could have started from scratch with less overall effort. The remainder were more or less frustrated.
Outcomes
Students learned a lot about the organization of one particular software package, but without the reinforcement of a successful conclusion for their e orts, it's unlikely they generalized this to organization of later projects of their own. This project was not successful as a learning experience for the class, but I learned a few things. Intelligent graduate students are not necessarily skilled programmers; the students who succeeded in the port were working in industry. Reading code is a skill, and absorbing a medium-size system is another skill. Although both skills are important in industry, few students with only academic experience Students have done other kinds of systems pro- have practiced them. Larger student projects gramming projects. should have milestones, to avoid binary success or failure.
3 Other Large Projects
3.1 Mach Threads
The idea was to take the publicly available 3.2 Remote File Server code for the Mach user-level C-threads pack- Seventy seniors wrote a remote lesystem. age from CMU [2] and replace the Mach sys- There were a series of due dates, and solutions tems interface with a Unix, VMS, or Win- to each stage were available after the due date, dows one. The C-threads code can use mul- so that slow students wouldn't be hopelessly tiple kernel threads, but doesn't require them. behind. It uses Mach memory-management primitives Stages were: to assign data structures, and includes some machine-dependent assembly language codeweek simulated local disk (in a le) with read for context switching. There are about a dozen 1 block, write block, allocate block using source les and about sixty pages of code albitmap and linked list (two di erent imtogether. The code is relatively well-written, plementations.) 3
week 3 week 5
local le system using inodes built on A trivial sample database makes debugbitmap implementation of stage 1. ging easier, but also lessens the appeal of the project. remote le system, using Sun RPC, built on local le system of stage 2.
4 Small projects
Outcomes
A series of small projects, each intended to be completed in a week or so, can be very satisfying to both student and teacher. Some of these emphasize measurement. Some of the more successful have been: measure process startup times. This helps to introduce them to the idea of doing statistics on measurements and give them some feel for experiment design. There isn't much challenge to the actual measurement, although this is often the rst occasion students have had to use fork()/process()/spawn() calls. Probability and statistics are prerequisites for our OS courses, but a handout on statistics for experimenters is helpful. measure context switch time. Students use Larry McVoy's signal benchmark [3] to measure context switch time on their system. It's an alternative to measuring process startup times, but doesn't show as much variation. measure the time for a page fault or mea-
Good students produced good systems with appropriate e ort. Adding the RPC environment to their repertoire pleased everyone. Valid criticism of the RPC tools enhanced everyone's appreciation for good software engineering. Students were engaged by the programming. There was a drill in le structures, and the experience of working on a larger system was valuable. Slower students were overwhelmed with the size of the project, although almost everyone nished. They would have been helped by more intermediate due dates, even without solutions. The project didn't emphasize the other concepts of the course, although it consumed most of the student e ort.
3.3 Object Database System
Grad students wrote code to follow record pointers and maintain caches of records from les in main memory. File data structures and transaction logging were built on this foundation.
sure the cache line size and total cache size in a running system. The schemes for
Outcomes
these two projects overlap, so a given class is assigned only one of the two. Cache measurements are more interesting to the class, but paging measurements are easier to do. The nal programs are short, but students usually have to discard several before they get results.
This relates well to caching and paging; students push their understanding of le-related system calls. Concurrency and synchronization are covered with a semi-realistic sca old for the readers-writers problem, a client-server message-passing scheme, and transaction logging and recovery. Since all of these are properly OS topics, the slight digression into data structures and navigation in object databases is probably harmless, but it is a distraction.
add deadlock detection to a simple transaction package. Students start with a
very simple transaction package, about
4
three pages of code, and modify it to detect and break deadlocks.
write `solutions' for dining philosophers, readers/writers... Students work up solu-
tions to classical synchronization puzzles. They have used pseudo-code, processes, a home-brew threads package, Sun lwp, and DECthreads to code these solutions, and they seem to be most satis ed with the experience when they can run the code on a commercial thread package (lwp or DECthreads.)
write a transaction manager. The soft-
ware is driven by commands from the terminal. It does logging, commit, abort, and crash recovery. The commands include transaction-id's, so the transaction manager must manage concurrent transactions, but students seem more comfortable with the single-threaded TM, than with the thread-based transactions of the Outcomes previous project, probably because they design all the data structures themselves. Small projects o er an opportunity for student clasroom presentations. People are proud of build a time-of-day clock based on their solutions, and the class is ready to unalarm() and its signal. A counter is in- derstand and eager to ask questions. More cremented every time a SIGALRM is re- than one student can present the same project, ceived, in order to maintain a running since their approaches and results will be diftime. The accuracy of the synthesized ferent. Small project presentations are easclock is measured. It varies dramatically ier to organize, and there are room for more from one system to another. of them in the term. However, only in small classes will every student be able to make a measure le sizes in your system and pro- class presentation. pose an appropriate le block size. This Small projects demand less of the time availis basically another go at the Satya- able for the total course, and are thus less narayanan study, and sometimes one of risky. If a small project fails to achieve its [4, 5, 6] is assigned as related reading. goal, the instructor gets another chance in the term. This allows projects covering topics like simulate multi-processor scheduling. A experimental design and statistics which may comparison of scheduling n servers with be less central to the course. either 1 queue or n queues. A range of loads is simulated; the students are surprised to discover how dicult simulation turns out to be. The simulation leads well into a lecture on simple queuing theory. Process synchronization
5 Topic Coverage
write client/server pair. Students write a The classical puzzles like dining philosophers
memo-server and associated client, using SUN RPC. I have used a variety of approaches including pseudo-code; as with the larger remote le system project, students like using RPC, which with all its frustrations feels like a real-world tool.
were originally o ered to make points about process synchronization, and projects built around them encourage students to learn to think in terms of concurrency and synchronization. Thread packages work well with semaphores, because semaphores are global
5
Topic
Process management interrupts threads processes transactions large-grained objects Process synchronization Memory Management Caching Paging I/O Models File Structures Experimental Design RPC
Projects 32-bit OS 32-bit OS either OS deadlock detection client-server either OS context-switch
alarm() clock
cache measurement 32-bit OS 32-bit OS object DB process measures remote lesystem
object DB page fault measures
16-bit OS process measures transaction mgr
deadlock detection classic puzzles
classic puzzles deadlock detection
alarm() clock
remote le server
16-bit OS remote lesystem page fault measures context-switch client/server
client-server
le measures le measures
Figure 1: Coverage of various topics by project
Paging
variables and seem appropriate to an environment where global variables are possible. One modest problem is that many thread packages are built around a monitor model, and using monitors for semaphores feels inelegant. Semaphores also t easily into a toy OS.
Topics one hopes to cover include non-paged memory management techniques, the variety of hardware support for paging, caching and replacement strategies, simulation as a tool for evaluating speci c schemes. Non-paged memory management was covered in the BIOS-based PC OS project. Asking students to write a single-process malloc() routine would be a shorter, selfcontained project to cover the same ground. One of the goals for the 32-bit PC OS was to have students write paged memorymanagement routines; these are hard to motivate with any less sca olding. As reported above, the results were mixed. Students need to think as hard about caching and replacement issues for the object DBMS project, and much less sca olding is required. With current prices, demand paging is less important to extend the size of memory than as an object lesson in data staging.
Message-passing schemes can be used in either a thread or process context. Signals are the most accessible interrupt-like mechanism, and they can be used either within a single process (e.g. alarm()) or between processes. However, hardware interrupts are conceptually simple, and the presence of sca olding to handle them is one of the best justi cation for toy OS projects. Deadlock-detection already has a bigger place in OS textbooks than in most operating systems or applications. A project to do deadlock-detection may thus be more of too much, but it does give a good feel for synchronization data structures. 6
I/O models
DOS debugging tools worked well, and leveraged student e ort. The 32-bit OS also motivated the students, even though I thought it was too much work. If students are involved, they can cope with inadequate documentation and tools. Students are willing to do a lot of work if the project excites them. Student
The importance of embedded systems justi es treatment of low-level I/O models. The curriculum and projects should cover interruptdriven I/O and DMA, if only because there are more people working at thhe lowest level than there ever were before. Toy operating systems is the most important ingredient in can provide a sca old for these projects, but motivation good projects. only keyboard and display I/O appear in my Students have a strong case of Not-Inventedproject list. Here syndrome, and would prefer not to read code. Projects which require students to inFile Structures corporate big chunks of NIH code also conmodels and abstractions. If the code The BIOS-based PC OS plays hard with DOS- isstrain too well-documented, the students lose the like le structures; a student is unlikely to opportunity to build their models, and come through the project without realizing might as well be reading a own textbook; if it is what each of the structures is for. Although not documented, we are not only channeling much less attention will be paid to other ways student thought, but setting a bad example. to do the same job, the foundation to easily On the other hard, students appreciate learngrasp them is in place. Alternatives have been ing about new tools. They like projects which covered in lecture, but have properly received introduce them to widely available tools like only the few hours that le structures deserve RPC, threads, or graphing packages. in the bigger picture. The remote le-system Weaker students do better with a rigid similarly exercises an inode-like le structure. schedule of relatively short-term deadlines. Rewards for the student are proportionSystem Structure ate to the e ort expended, once the Students already have a lot of experience writ- student-perceived threshold of acceptability is ing short programs. Short projects draw achieved. Student submissions which they on this experience. The client-server project perceive as inadequate create doubts which expands their repertoire of program struc- mask the learning experience. Intermediate tures; so do thread packages. My other short milestones are important. projects do not, but all of the larger projects The strongest students, those for whom a project requires few new concepts and takes do so, to greater or lesser extent. Both toy OS projects are micro-kernels. little e ort, will also be rewarded proportionOnly the 32-bit OS has visible interrupt han- ately to the e ort expended, and it makes dling. However the clock project uses signals sense to include extra bells and whistles to stretch them. analogously. Informal documents are part of every project, including design descriptions, operating instructions, debugging diary, as well as code and output. If all students produced uniThe BIOS-based OS project was highly suc- formly good documentation of their projects, cessful; the students were very motivated. grading them would be easy; a speci c break-
6 Lessons
7
down of what I hope to read helps keep them at least uniform. Students who lack con dence
of the 10th Symposium on Operating System Principles, December 1985.
in their programming are reassured by the opportunity to receive credit for supporting ma- [6] M. G. Baker, J. H. Hartman, M. D. Kupfer, K. W. Shirri , and J. K. Ousterterial. All students are helped by practice prehout, \Measurements of a distributed le senting their ideas. system," in Proceedings of the 13th SymThere are not enough hours in a term to posium on Operating System Principles, cover every idea with a project, and other pp. 198{212, October 1991. learning modes need to be incorporated into the course. In addition to lecture, I use paper reviews, textbook review questions, and exams. An operating systems course is a good place to use the seductive appeal of programming projects to help students shape their own learning experience. Assignments and supporting materials for many of these projects may be found at http://cs.wpi.edu/~ staylor/os-projects
References [1] D. J. Delorie, \The djgpp C compiler for DOS." http://www.delorie.com/djgpp. [2] E. C. Cooper and R. P. Draves, \Cthreads," Tech. Rep. CMU{CS{88{154, School of Computer Science, Carnegie Mellon University, February 1988. [3] L. McVoy and C. Staelin, \lmbench: portable tools for performance analysis," in Proceedings of the USENIX 1996 Annual Technical Conference, pp. 279{94, USENIX Assoc; Berkeley, CA, January 1996. [4] M. Satyanarayanan, \A study of le sizes and functional lifetimes," in Proceedings of the eighth Symposium on Operating Systems Principles, pp. 96{108, ACM, 1981.
[5] J. K. Ousterhout, H. D. Costa, D. Harrison, J. A. Kunze, M. D. Kupfer, and J. G. Thompson, \A trace-driven analysis of the unix 4.2 BSD le system," in Proceedings 8
