Operating Systems Projects Built on a Simple Hardware Simulator

Transcription

1 Operating Systems Projects Built on a Simple Hardware Simulator John Dickinson Department of Computer Science University of Idaho Moscow, ID johnd@cs.uidaho.edu Abstract Effective teaching of operating system concepts requires projects. This paper describes a series of operating system projects all based on a simple hardware simulator that have been used to teach operating system concepts at the undergraduate level. A key feature of this approach is the use of a simple but realistic hardware model upon which an operating system is progressively built. The hardware simulator evolves as the operating system evolves. 1 Introduction Operating systems are the magic that makes all computers perform their miracles. Teaching about operating systems requires that the instructor explain and reveal all the secrets behind the magic. There is no better way to do this than to have the students create their own operating system, thus discovering the secrets for themselves. There are several small operating systems that have been used as test laboratories for operating system classes [1,3,4,5,6,7,9], but most of these involve many, many pages of code. With so much written code the student has a difficult time uncovering details. Often these systems are complete enough to run and so there are few important functions left for the student to write. For example, OSP by Kifer and Smolka [6] involves about 40 code and header files and about 13,000 lines of code. In comparison, version 0 of this project involves 5 code and header files and less than 800 lines of code. Version 6, which includes all of virtual memory management, involves the same number of files and about 3,000 lines of code. The approach described here uses a simple, minimal but realistic hardware simulator upon which the students write an operating system in stages. This implementation was first used in and at that time the instructor and students jointly created the hardware through discussions about which functions could or should be performed by hardware and which functions could or should be performed by software. The author returned to the course in the fall of 1998 and since that time the hardware has become fixed and the operating system functions more permanently defined. It is argued here that this approach is superior when the goal is to teach undergraduate students the fundamental issues involved with operating systems. 2 Hardware Simulator A key to this method of teaching is the use of a simple hardware simulator. This approach has been used to teach computer organization concepts [2]. What exactly does a simple, minimal but realistic hardware simulator, mean? Let us explain by using an example. In order to provide the hardware support for CPU process scheduling only two instructions are needed: a generic compute instruction and a halt instruction. A process can be thought of as a sequence of compute instructions with a terminating a halt instruction. This is often called a CPU burst [8]. The operating system does not care what is being computed, it is only concerned about issues such as which process to schedule next and how long that process will be allowed to run. For this one function of an operating system, there is no need for the hardware to simulate registers or a variety of calculating instructions or any other aspect of real CPU activity. These are all irrelevant to the operating system when it is dealing solely with CPU process scheduling. One of the secrets about operating systems is that they are not constantly watching processes and handling issues as they arise. An operating system is only involved when, for one reason or another, a process can no longer proceed on its own. Thus once a scheduled process begins to execute, the running process has control of the CPU until an event such as an interrupt or exception occurs.

2 To allow the operating system to deal with input/output interrupts a generic input/output instruction is added. This additional instruction forces the operating system to transition processes through Ready, Running, Waiting and Terminated states. Processes can then be constructed as a sequence of compute and I/O instructions ending with a halt instruction. The operating system can now transition processes through all the necessary states as processes execute their instructions. It is not necessary to simulate actual input/output operations, only that there is time between the start of the I/O operation and the interrupt that signals the end of the operation. If a specific device or calculation is used by the operating system to transition processes, then it could be simulated, but since the operating system is only involved with processes during the handling of interrupts or exceptions, the interaction between the hardware and software can be simulated in a simplistic manner. Further additions to the hardware simulator are described below as we discuss the various versions of the operating system. 3 Versions of the operating system Versions of the operating system build upon one another. Each version retains the functionality of the previous version and adds new functionality. The series of versions of the operating system schedule processes, deal with input/output, manage real and virtual memory, interact with file systems, and utilize internationalization. There are nine versions at the present time. Version 0: CPU scheduling and simple state transitions. The hardware simulator includes only two instructions: INST and HALT. All processes are considered to be a single compute burst. This is a common view of processes when algorithms for scheduling processes are being compared [8]. The operating system should include several scheduling algorithms, such as first come first serve, round robin, and shortest job first. This version of the operating system is very short (less than 150 lines of code) and it is sometimes given to the students as a completed system to allow them to become familiar with the components of the hardware simulator and the operating system. The hardware simulator program is about 125 lines of C code and the main program is about 400 lines of C code (most of this code is debugging and display code). Version 1: Simplistic I/O. This version adds input/output operations to processes. One new instruction is added to the hardware simulator: IOINST. The IOINST instruction does a generic input/output operation. Any input/output operation is actually initiated by the operating system and then there is some time that passes while the physical device does the actual operation and then an interrupt occurs that signals the completion of the input/output operation. The essential aspects of this process are built into the hardware simulator. All input/output operations begin with a system call (that is, a call to the operating system) that initiates the input/output operation. The time that the physical device takes is characterized in the hardware simulator by some random time between the start of the I/O and the completion of the I/O (i.e., the interrupt). Specifically, the hardware simulator uses a random number generator to select a time in the future when the device will be finished and schedules an interrupt at that time. The hardware simulator checks for scheduled interrupts every time the system clock is advanced. When the hardware simulator comes to a time when an interrupt is scheduled to occur, it calls the interrupt function. The interrupt function is part of the operating system, a function that the students write. In this version of the operating system, the handling of an interrupt involves no real data, but does involve changing the transition state of the process whose input/output has just finished. This version of the operating system has a full set of transition states: Ready, Running, Waiting and Terminated. [8] Version 2: Realistic I/O and deadlock prevention. This version of the operating system makes the simulation of input/output more realistic. It adds the concepts of devices and classes of devices. So input/output operations are directed at specific devices, specific devices cause interrupts, devices belong to a device class and processes must request devices from a device class. Deadlock is also addressed in this version. The Banker's algorithm [8] is used to prevent deadlock. There are two new instructions and one modified instruction. To request a device a process uses an OPEN instruction. The OPEN instruction asks for a device from a specific device class and if successful assigns the granted device an I/O descriptor or unit number that is used by the process for actual input/output operations. To release a device a process uses a CLOSE instruction. The IOINST is modified so that the input/output operation is performed on a specific device by supplying the I/O descriptor or unit number. An OPEN instruction does not always result in a device being allocated to the process. There may be no available devices in the device class or the Banker's algorithm might detect a potential deadlock condition. Thus all OPEN instructions are function calls to the operating system to request the allocation of a resource. Using deadlock prevention this version can run any collection of processes that could have finished individually. Version 3: Virtual memory, part 1. Virtual memory is complex and confusing for many students, so there are four versions of the operating system that build toward a comprehensive virtual memory system. This first virtual memory version assumes that there is enough real memory so that there is always a free frame available to allocate whenever one is needed. This version could function

3 adequately without any new instructions but one new instruction is added. The LOAD instruction, which loads the contents of a memory location into an accumulator, is added so that virtual pages might be brought into RAM in an order that is not strictly sequential. Frames in RAM are loaded from a simulated disk using a DMA operation. The DMA operation uses a device in the resource class specifically designated as the device class to be used for DMA operations. The primary issues in this version deal with the creation of page tables and the allocation of RAM. There are also some memory management issues, such as frames in RAM need to be locked while the DMA operation loads the data into the frame. Version 4: Virtual memory, part 2. This version uses limited primary memory. Therefore, frames in memory must be reused. An algorithm such as FIFO or LRU [8] is used to select victim frames in RAM. No new instructions are added in this version. The primary issues in this version deal with the reuse of frames in RAM. With limited primary memory, free frames are used up quickly and so further memory allocation is accomplished by selecting a victim frame currently used by another process, updating the relevant page tables and using DMA to load the data into the selected victim frame in primary memory. In order to support a wide variety of page replacement algorithms, the hardware simulation keeps track of many parameters associated with each frame used in primary memory, such as time frame loaded, time frame last referenced, number of frame references, a reference bit, etc. Page replacement algorithms can use any of this information in an effort to minimize page faults. Version 5: Virtual memory, part 3. This version allows frames in memory to be modified. Thus when selecting a victim frame it might be necessary to write the frame out to disk before reading the new frame from the disk. A new instruction required for this version is STORE, which writes the contents of the accumulator to a memory address. The primary issues in this version involve saving modified frames to disk. The hardware simulation keeps track of a modify bit that the system must use to prevent the loss of data. Version 6: Virtual memory, part 4. The previous versions that deal with virtual memory can find themselves thrashing, where paging activities become the dominant activity for the system. This version monitors and prevents thrashing. There are many methods that can be used to prevent thrashing and the students are allowed to select the method they prefer. Essentially, the operating system needs to monitor CPU utilization, the page fault rate or some other measure of memory management efficiency. This version is able to handle any set of processes as long as the amount of primary memory is greater than the minimum required to process the most complex single instruction. For example, one can lower the amount of primary memory to just six frames and any set of processes can still be run to completion by the system. For this case, there is a great deal of memory contention, but the operating system is able to decrease and increase the level of multiprocessing to eventually get all processes to complete. One of the advantages of this simulation is that is can focus the attention of students on single issues. For example, when dealing with virtual memory management, the amount of primary memory can be severely constrained to emphasis the role of the memory manager. Simulations for version 6 often have only 32 bytes of primary memory arranged into 8 frames of 4 bytes each. Version 7: File system. This version introduces a file system. All interacts with files or data in previous versions used the program or process file. This version allows a process to read or write to an existing file or to create a new file. Several new instructions are needed: FILEOPEN, FILECLOSE, READ and WRITE. The file system created for this version is a simple, flat structure. There is only a single top-level directory. The issues in this version concentrate on the management of files on the simulated disk, rather than on the complexity or efficiency of the file structure. Certainly a further version could be added to make the file structure more realistic. Version 8: Internationalization. This version internationalizes the operating system. During the initialization process for the operating system, a language is selected. Once the language is selected, then all the messages from the operating system are given in that language. Also all data is reported according to the language selected. This effects dates, decimal points and other formatting issues. Each student is required to provide data files for at least two languages. If a student only knows a single language, then they are asked to use something like pig latin as their second language. This version could have been done at any stage in the progression of versions. It was placed at the end only because the topic is generally discussed near the end of the class. It would have been an easier project if it had been done earlier and then utilized through the project series. 4 Organization of the projects in class Each version of the operating system is created as a set of three C code files and two header files. The three C code files are the hardware simulator, the main program that initializes the operating system and the operating system functions produced by the students. Header files are provided for the hardware simulator and the main program.

4 The hardware simulator and main program files (and their header files) are provided for each version of the operating system at an ftp site through a web page. The hardware simulator contains all the functions of the hardware and is purposefully ignorant of any notion of a process or any other operating system function. The main program initiates the entire simulation, reads in a parameter file, creates processes from files and has all of the debug print routines for the simulation. The header files contain function prototypes, constant definitions and major data structure declarations. A parameter file is used by each version to allow the student to modify a wide variety of hardware and software parameters and to set/clear various debug option flags. Some examples of hardware parameters would be memory size or the number of devices in a resource class. Some examples of software parameters are the CPU scheduling algorithm or the page replacement algorithm. Some examples of actions allowed by the debug option flags are printing instructions or printing the process control blocks. The debug print routines are located in the main program and they can be used to print out at appropriate moments a wide variety of the information generated by the hardware and software during the simulation. These allow the student to follow a trace of a wide variety of activities within the operating system. The usefulness of the parameter file is that it allows each version to serve as an experimental laboratory for additional projects. One can modify the amount of real memory to see how the overhead for virtual memory changes. One can run the same job stream using several different CPU scheduling algorithms or several different page replacement algorithms. 5 Some Lessons Learned The primary lesson learned it that small simple systems can be used to effectively teach operating system concepts. This approach allows the student to concentrate on the operating system issues in detail. At the same time, this approach allows the student to experiment with their implementation of an operating system by modifying a wide range of hardware and software parameters. As the projects build upon each other, the entire code becomes larger and larger. At some point students are faced with a version of the system that is not working correctly and often this causes them considerable amount of debugging time. While every effort has been made to keep the overall complexity of the system small, the project gets larger simply because the progression of operating systems are doing more and more tasks. Larger projects require more planning and design. The students that are able to plan and design their code are more successful. Software engineering approaches to these projects have worked very well. The first class that used this project approach attempted to do fewer but larger projects. For example, all of virtual memory management was done as a single project, all of devices and input/output was done as a single project. The students were not able to plan adequately for those larger projects. The complexity of the details prevented them from advancing as far as seemed reasonable during a semester. This is why the projects now include stages of some elements such as memory management. Some concepts are easier to learn than others. Process scheduling is an example of an easy concept and virtual memory is an example of a concept that appears to be easy but is not. But it is safe to say that every student who completed a project learned the concepts involved with that project. Students learn from both their successes and failures. They understand the complexity involved in a modern commercial operating system but they more sympathetic to the commercial operating systems that they use. In the end, the students have an appreciation for and a clear understanding of an operating system. Students learn from doing. No student who has complete these projects has left the course with any unexplained mystery about how an operating system works. 6 Availability of the Projects Descriptions of the projects and code for the projects can be found on the following web page (or by writing to the author). References [1] Toby S. Berk, "A Simple Student Environment for Lightweight Process Concurrent Programming under SunOs," SIGCSE Bulletin, March 1996, pp [2] Robert A. Campbell, "Introducing Computer Concepts by Simulating a Simple Computer," SIGCSE Bulletin, September 1996, pp [3] Joel W. Carissimo, "XINU - An Easy to Use Prototype for an Operating System Course," SIGCSE Bulletin, December 1995, pp [4] Douglas Comer and Timothy Fossum, Operating System Design, Vol. I: The Xinu Approach, Prentice- Hall, [5] Charles Crowley, Operating Systems, A Design- Oriented Approach, Irwin, 1997.

5 [6] Michael Kifer and Scott A. Smolka, OSP, An Environment for Operating System Projects, Addison- Wesley, [7] Mauro Morsiani and Renzo Davoli, "Learning Operating Systems Structure and Implementation through the MPS Computer System Simulator," SIGCSE Bulletin, March 1999, pp [8] Abraham Silberschatz and Peter Baer Galvin, Operating System Concepts (Fifth Edition), Addison- Wesley, [9] Andrew S. Tanenbaum and Albert S. Woodhull, Operating Systems, Design and Implementation (Second Edition), Prentice-Hall, 1996.