Comer, Douglas E.

English

Purdue E-Pubs

Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1986 The Costs and Benefits of a Teaching Laboratory for the Operating Systems Course Douglas E. Comer Purdue University, comer@cs.purdue.edu Report Number: 86-589 Comer, Douglas E., "The Costs and Benefits of a Teaching Laboratory for the Operating Systems Course" (1986). Department of Computer Science Technical Reports. Paper 508. https://docs.lib.purdue.edu/cstech/508 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact epubs@purdue.edu for additional information. THE COSTS AND BENEFITS OF ATEACIllNG LABORATORY FOR THEOPERATING SYSTEMS COURSEDouglas ComerCSD-TR-589March 1986The Costs and Benefits of a TeachingLaboratory for the Operating Systems CourseDouglas ComerComputer Science DepartmentPurdue UniversityWest Lafayette, IN 47907TR·CS·S89March, 1986During the 1985-86 academic year. the graduate-level operating systems course atPurdue University witnessed a dramatic shift in emphasis and content when we aug-mented the classroom lectures with supervised, hands-on laboratory work. The lecturescontinue to present concepts, but focus has moved from the traditional survey of topics inconcurrent computing to topics more closely related to system design. Meanwhile, thelaboratory fills two important needs: it gives the student a concrete example of the prin~ciples discussed in class, and it introduces tools and techniques used to design, build, andmanage complex systems.Results from the first two offerings of the laboraatory show that it is an outstandingsuccess. Students enjoy the opportunity to learn and use good programming tools, and tosee how a large, complex system fits together. They often spend time outside therequired laboratory hours extending assignments, and" experimenting with the system.Surprisingly, students who learn concrete system details in lab seem to understand con-cepts better than students from previous semesters who concentrated all their efforts onstudying abstractions.This report gives a short history of the move to laboratories, and summarizes ourexperiences with the operating systems lab. It discusses the assignments, laboratorystaff, and facilities, and assesses costs including the hardware, software, and space used.-2-1. IntroductionIn fall, 1985, the Computer Science Department at Purdue University moved into anewly remodeled building that had been carefully planned to encourage experimentalresearch and encourage increased emphasis on experimentation in courses. In the newbuilding, 22% of the floor space was devoted to laboratories that are being used forteaching and research.Laboratory space in the new building was not an accident, but part of a consciousplan to change the department. The shift to experimental computer science began overfive years earilier when we realized that both our courses and research suffered becausefaculty (and students) were deprived of adequate experimental facilities. The few facultywho managed to acquire equipment had (literally) no floor space to use it. Most realizedlhat without adequate space, power and cooling, or professional staff, equipment wasuseless and experiments hopelessly difficult. So when the opportunity came to com-pletely redesign the interior of a building, the department chose to allocate significantportions of the space to laboratories for teaching and research.While the new building was still a dream, we proposed new experimental researchprograms, and contemplated how undergraduate and graduate courses could use labora-tory facilities. We presented the administration with a plan to make programming labs arequired part of the undergraduate core courses, and outlined the need for instructionallaboratory space. We requested equipment grants from vendors and made good use ofthe resulting donations. We started to offer graduate seminars in the areas of networksand operating systems, allowing a few advanced Ph.D. students to use the meager facili-ties.Students, who were eager for hands-on experience and willing to test their ability toput knowledge to use on real software, made the early systems seminars exciting and pro-ductive. It became apparent that we would soon have more students interested in takingthem than we could accommodate comfortably.2. The Xinu ProjectOne of the early systems seminars focused on the design and implementation of ahierarchically structured operating system. Digital Equipment Corporation had donatedfive LSI 11 microcomputers to the department, and these became the basis for a proto-type. We set the goal of producing a system capable of supporting concurrent processingand network connections among the machines. The real goal, of course, was to under-stand operating system components, and to find an organization that was both useful andinteresting.Surprisingly, living with the constraints of microcomputers proved to be valuablebecause it made us consider the design carefully. Small memory size forced economy ofspace; slow processor speed forced economy of code. Early in the project, we decided tofollow a hierarchical design in which successive levels of functionality are built usingprimitives provided by lower levels; in the ideal case, no function would be duplicated.The resulting system, called Xinu, provides impressive functionality in very little space.It is both useful and elegant.The Xinu project worked well because it provided a faculty member with the oppor-tunity to explore operating systems design and students an opportunity [0 become- 3-directly involved in the project In the first fews sernmars. st'udents built cross-development tools like compilers, loaders. and linkers, as well as downloaders anddebugging aids. They tracked down hardware details and conducted experiments tosolve small problems. Other students read design notes and code carefully (even before acompiler was available). Within eight weeks we had successfully downloaded and exe-cuted the basic parts of an operating system; by the end of the first semester we demon-strated a ring of LSI lIs sending packets.3. Need for a TextDuring the time Xinu was built, the Department began to discuss introducing moreexperimentation into conventional courses. Although extremely successful, systemsseminars involved only between 6 and 12 of the most advanced students each semester.We talked abollt how to provide more students with the same experience. For example,Xinu technology provided a convenient environment for learning about operating sys-tems and for testing new ideas. But the standard operating system course containedmuch material, and it was not obvious how to squeeze in experimentation as well, espe-cially if students had no background.The lack of a textbook posed the most serious problem. Few of the existing textsdiscussed operating system design at all. Most surveyed topics related to operating sys-tems, dealing only with abstractions or languages for concurrent programming. Studentswere left with little or no information about the internals of a system, or worse, theimpression that a special language or compiler was needed to build an operating system.4. The Four Pieces Fall Into PlaceOne: A Tex,. During the 1982-83 academic year, while on sabbatical at Bell Labs,the author wrote a textbook on operating system design using the Xinu system as anexample [COJvIE84]. The text provided one of the essential ingredients for a laboratory-oriented operating systems course, a source of infonnation on system structure anddesign details.Two: Student Background A second key ingredient occurred when faculty teachingthe compiler course switched to a UNIX-based environment, and began using C theimplementation language. Having written a compiler in C, students were prepared toread and write C code, the implementation language for Xinu.Three: Facilities. The third ingredient needed for a laboratory was computing facil-ities. During the 83-84 academic year, we hooked our LSI lIs to an instructional UNIXsystem, and had students cross-compile and download Xinu as part of their programmingassignments. Although high machine loads made the environment less than ideal, ourearly experiences with experimental facilities reinforced our belief that they would makea significant improvement in the way students learn. Our efforts convinced the universitythat we had made a serious commitment to laboratories, and showed that we desperatelyneeded better facilities.We submitted proposals to Digital Equipment Corporation, and by late spring, 1985,we had acquired a VAX 11/785, 8 LSI 11/23 systems, and two Microvax I machines forthe lab. The LSI 11/235 were faster than the early LSI 11125, and had Ethernet connec-tions, providing an environment that supported network communication as well as- 4-conventional operating system development. The Microvax I systems provided anenvironment with paging hardware, allowing students to experiment with virtualmemory. More important, the VAX 111785 provided the computing power needed tohave multiple students in a lab working concurrently on their own operating system.Four: The Space. The final requirement for a lab is one of the most difficult in mostuniversities - space. In our case, the department was preparing to move, and buildingrennovations had been planned while we were acquiring equipment and planning labs. Infact, a Xinu lab had been included in some of the earliest building plans. Thus, the labwas in use shortly after the move.5. The Xinu LaboratoryCurrenr Faciliries. The Kinu lab currently consists of 986 square feet of fioor spacepartitioned into two areas by a semipennanent, sound-absorbing wall 7 feet high. Theouter area consists of 15 work areas, each with a 3X5 table and desk area, CRT tenninalas well as a white board which is used for instruction. Behind the wall are 7 machineracks that house 17 Digital Equipment Corporation LSI 11s, 5 Intel Corporation 8086machines, 2 Microvax I systems, and miscellaneous other systems. The main computingengine is a dedicated VAX 11/785, located in an adjacent machine room.Purpose. The Xinu lab supports both instruction and research. Students in theoperating systems course are required to enroll in one of the 3-hour sections where theygo each week to work on assigned problems. The lab problems involve modifying, rest-ing, measuring, or extending the operating system. Additional lab hours are provided toallow students to access the facilities outside their assigned formal lab session. The labalso supports advanced students in a graduate systems seminar, as well as severalindependent study projects each semester. Finally, the lab is available to Ph.D. studentsworking in the general area of operating systems.Supervision. A key part of the instructional laboratory concept is supervision. Thelab is not merely a computing facility or a quiet place to work; it is a teaching facilitywhere students work under the supervision of lab instructors. We want students to learngood habits, to use tools well, to understand the concepts underlying design, and to learnhow to construct and debug systems systematically. Thus, the focus shifts from an endproduct (i.e., the program) to a process (i.e., the design and implementation).Personnel. At present, two half-time Teaching Assistants assigned to the operatingsystems course supervise the lab (in addition to their usual duties in the course). Theygive a short background lecture at the beginning of the lab and explain the problem to besolved. During the lab, they visit each station, monitoring students, offering advice, andanswering questions. At the end of the lab period, they check each student's progressand assign a grade of superior, satisfactory, or unsatisfactory. They invent supplementalsoftware and make sure the hardware and software are operating correcdy. The assis-tants have taken an active role in suggesting problems and preparing small pieces ofsoftware for the assignments.Modus Operandi. in the lab, students use the 11/785 and UNIX* Timesharing sys-tem for software development activities. They prepare a new version of their operating'" UNIX is a trndemark of Bell Labs.- 5-system and then download it into one of the LSI 11 machines. Once resident, theiroperating system executes independentlyJ and the software we supply automatically con-nects the student's tenninal to the console of the LSI 11 to observe results. If the operat-ing system crashes, the student can restart it, abandon it, or upload a copy of the LSI 11memory to the VAX. Once a copy of the memory has been uploaded, the student can usea post mortem program to pick through the image and print out information on !heactivity of each process.6. Student ReactionStudent reaction to the hands-on laboratory experience has been almost unanimousand positive. In the beginning, we worried that the best students would complete theassigned problem and leave, but that has not been a problem. Students with previous sys-tems experience are eager to extend the assignments, and to explore additional parts ofthe operating system. Even the students who find the assignments difficult indicate thatthe lab is a positive learning experience.Because the operating system course is not required, enrollment gives a good indi-cation of student interest. At the beginning of Spring semster 1986, the course was filledto capacity (40), and an additional 16 students were waiting for admission. The systemsseminar was also flooded with 15 people participating. Such enrollments are especiallysignificant in our environment,. because students often seek advice on courses from theirpredecessors and unpopular seminars vanish quickly. Thus, one generation of students isencouraging the next generation.Another measure of student interest is their willingness to tolerate inconvenience.Before fall of 1987, laboratories were not part of the official registration, so students hadto adjust their schedules to squeeze in a laboratory on the first day of class. In Spring,1986, when it became apparent that we could not accommodate the entire class duringthe working week, the students themselves suggested an evening lab.Finally, we have had increased interest in teaching assistantships. Assistants enjoythe opportunity to devise interesting exercises, and often spend extra hours helping stu-dents with both the concepts and system details.7. Lessons Learned.In general, the laboratory has been a positive and stimulating experience. Studentsshow genuine excitement about taking concepts out of the classroom and use them tomake real systems run. Beyond that endorsement, we can relate several specific lessonslearned from the labs.There is no replacemenr for experience. We have found that students who work ona real system appreciate the intellectual content of the course much more than those whodo not. Faced with the difficult task of modifying or extending a system, theycomprehend the design issues, and seek principles that will help them solve problems.We use their inquiries to point them to fundamentals, relieving us from constantly tryingto motivate them to read and study.Robust hardware and sofnvare is needed. Because students push our systems to thelimit,. having a reliable, robust environment is essentiaL This many seem absurd in thecontext of a lab that allows students to write operating systems that completely control a- 6 -machine. In fact, the students' code often causes the microcomputer to halt in a catas-trophic way. If any part of the support environment is unreliable, however, students tendto blame it for their problems. Thus, we need to be able to depend on every peice wegive them so we can confidently point to their work as the problem. They need to know,for example, that our compiler and downloader produce a reliable, correct translation oftheir program; that our library procedures are correct and robust; and that our hardware isreliable and fault tolerant.Having a design-orienced text is essential. Our lab requires studems to apply con-cepts to practical, working systems. The lab concentrates on system details, tools, andthe problem to be solved; students depend heavily on the text for background infonna-tion. Texts that discuss only abstract concepts leave them unable to see how conceptsapply to real systems, whereas texts that present case studies concentrate on details andfail to associate concepts with the code. Students need a text that bridges the gap andshows principles of design that translate concepts into working systems.Labs should be imegrated wich che course. Early laboratory assignments grew outof conventional programming exercises. They used laboratory work to reinforce ideas inthe weeks following their presentation in class. We found by trial and error that closecoordination between lab and class works much better. \Ve now try to coordinate assign-ments so that laboratory work parallels topics in class, extending and motivating theclassroom presentation. As a result, labs deepen and broaden understanding.Experience Wich Real Machines is Helpful. The Xinu lab grew from work on realmachines, and in the beginning we wondered whether students would learn more from asimulated environment. In particular, we were worried that giving students a rawmachine would make their sysrems too difficult to debug. From previous experiencewith a simulated environment [Comer76] we knew that they could provide detailed diag~nostics and reproductability, making it much easier to write and debug systems. As itturns out, having a real machine has worked well in three ways. First, students haveadapted to real machines better than expected. Although using real machines makesdebugging difficult, they have accepted the challenge and worked hard to make theircode correct. Second, dealing with hardware has added a sense of realism to the lab. Formany students, the lab is their first experience with machines that they can touch andcontrol. They find it satisfying and exciting to know that their operating system is notjust a toy. They take pride in making their systems work correctly. Third, having realhardware has helped us expand and try new projects. Because it is possible to attach newdevices, or to interconnect machines, students have been able to experiment with newdisks, vinual memory, serial line interconnection among systems, and Ethemets.Operacing System Design Is Best Understood Through Experience. Perhaps themost important lesson we have learned is about teaching operating systems. Over twodecades of basic research has taught us much about operating systems. We know muchabout individual system components, and we even know good ways to organize them.We understand how to build reliable, useful systems, and how to reason about them. It istime to shift emphases from courses that talk about operating sysrems to courses thatteach students how to build operating systems. There are two aspects to systembuilding;abstract concepts and practical knowledge. The combination of a course thatemphasis concepts and a lab that emphasizes practical systems building satisfies both.The lab pushes students closer to the design process. They appreciate the difficulties of- 7-design and learn to assess the consequences of design decisions. They see, first hand,how scientific principles guide design, and learn that concurrency is both subtle anddeep. They learn that a real operating system is among the most difficult programs toconceive, understand, or modify. They grasp the importance of concepts and learn toolsand techniques needed for system design.References[Comer76] Comer, D.,"HAU411 Simulator: Software Support for a Coursein Operating Systems," froc. Texas Con! on ComputingSysrems, Austin, Texas, 1976, 152-156.[Corner84] Comer, D., Operating System Design: The Xinu Approach,Prentice-Hail, 1984.

The Costs and Benefits of a Teaching Laboratory for the Operating Systems Course

https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1507&amp;context=cstech

The Costs and Benefits of a Teaching Laboratory for the Operating Systems Course

Abstract

Similar works

Full text

Available Versions

Purdue E-Pubs