OSP?An Environment for Operating System Projects
Michael Kifer and Scott A. Smolka
Department of Computer Science
SUNY at Stony Brook
Stony Brook, NY 11794-4400
OSP is both an implementation of a modern operating system, and a flexible environment for generating implementation projects appropriate for an introductorycourse in operating system design. It is intended to complement the use of most standard textbooks on operating systems and contains enough projects for up to three semesters. These projects expose students to many essential features of operating systems, while at the same time isolating them from low-level, machine-dependent concerns. Thus, even in one semester, students can learn about page replacement strategies in virtual memory management, cpu scheduling strategies, disk seek time optimization, and other issues in operating system design.
OSP consists of a number of modules, each of which performs a basic operating system service, such as device scheduling, cpu scheduling, interrupt handling, file management, memory management, process management, resource management, and interprocess communication. By selectively omitting any subset of modules, the instructor can generate a project in which the students are to implement the missing parts. This process is completely automated by the OSP Project Generator, included in the distribution. Projects can be organized in any desired order so as to progress in a manner consistent with the lecture material.
The OSP Project Generator provides the instructor with a convenient environment in which to create projects. It generates a ?partial load module? of standard OSP modules to which the students link their implementation of the assigned modules. The result is a new and complete operating system, partially implemented by the student. Additionally, the project generator automatically creates ?module.c? files containing procedure headings and declarations of requisite data structures for each of the assigned modules. These files can be given as part of a project assignment in which the students are to fill in the procedure bodies. This ensures a consistent interface to OSP and eliminates much of the routine typing, both by the instructor and by the students.
The heart of OSP is a simulator that gives the illusion of a computer system with a dynamically evolving col-
lection of user processes to be multiprogrammed. All the other modules of OSP are built to respond appropriately to the simulator-generated events that drive the operating system. The simulator ?understands? its interaction with the other modules in that it can often detect an erroneous response by a module to a simulated event. In such cases, the simulator will gracefully terminate execution of the program by delivering a meaningful error message to the user, indicating where the error might be found. This facility serves both as a debugging tool for the student and as teaching tool for the instructor, as it ensures that student programs acceptable to the simulator are virtually bug-free.
The difficulty of the job streams generated by the simulator can be dynamically adjusted by manipulating the simulation parameters. This yields a simple and effective way of testing the quality of student programs. There are also facilities that allow the students to debug their programs by interacting with OSP during simulation.
OSP was developed at SUNY, Stony Brook, and borrowed
several important ideas from an earlier project
headed by Art Bernstein. The underlying model in
OSP is not a clone of any specific operating system.
Rather it is an abstraction of the common features of several
systems (although a bias towards UNIX can be seen,
at times). With the exception of the modules for interprocess
communication, the OSP modules were designed to
hide a number of low-level concerns, yet still encompass
the most salient aspects of their real-life counterparts in
modern systems. Their implementation is well-suited as
the project component of an introductory course in operating
systems. A more advanced project can be built
around the two modules that deal with interprocess communication.
Their design is more detailed and gives students
the opportunity to work in a realistically ?dirtier?
OSP is documented in the following book:
OSP ? An Environment for Operating System Projects, Michael Kifer and Scott A. Smolka, Addison-Wesley, ISBN 0-201-54887- 9 (1991).