Download Instructional Operating Systems Programming

Instructional Operating Systems Programming
The College of New Jersey
Keith Trnka
Submitted in partial fulfillment of the requirements of CMSC 499
Abstract
The process of learning operating systems theory without programming
experiences challenges many students. A number of operating systems programming
environments have been developed for use in graduate and undergraduate courses. My
studies identified and investigated instructional operating systems for use at The College
of New Jersey in an undergraduate operating systems course. So far, OSP 2 has been the
easiest for student use.
Introduction
Learning the concepts of Operating Systems can be a daunting task for a student,
especially without hands-on examples. It is confusing to read a little material about
scheduling algorithms and not have a CPU scheduler to experiment with. Graphical
examples can assist the professor in teaching the scheduling algorithms, but what about
victimization of used memory or file system structures? The best way for the student to
understand the importance of these concepts is to see their role in a complete operating
system.
Although it would be nice for a student to watch Windows, Solaris, or Linux
dispatch threads and connect to devices, these operating systems are too complicated for
an introductory course. Even if the students were able to understand the hundreds of
threads running at a time, there is no simple way to watch a real operating system and the
concepts it implements.
Operating systems in production grade systems are too much for a student to
handle, so some professors have decided to write operating system environments that a
student can both understand and experiment with. The programming environments I have
evaluated are Nachos and OSP 2.
Nachos
Nachos is a MIPS-based operating system written by Thomas Anderson at the
University of California, Berkeley. It is actually two pieces of software: a MIPS emulator
and a MIPS operating system. The operating system component of Nachos runs within
the hardware simulator of Nachos. The MIPS simulator is not for the student to
understand or program with; it merely provides a means of testing an operating system
within an existing operating system. In other words, a course could run and test Nachos
within SunOS, for example. This shortens the edit-compile-debug cycle greatly. The
operating system component to Nachos is complete and working; upon compilation any
DEC MIPS program may be executed.
The task for students using the Nachos system is to add functionality or extend
existing features. All C++ code is distributed with the Nachos package, so students are
given complete control over the algorithms used in the operating system. This allows a
student to investigate any virtual memory management scheme or any scheduling
algorithm. A professor is given the flexibility to create original assignments for Nachos,
aside from the suggested projects defined by Thomas Anderson.
Nachos is a very flexible environment for operating systems programming in
courses. All in all, Nachos allows students to have a thorough hands-on experience in
operating systems.
OSP 2
OSP 2 is an operating system programming environment written in Java by
Michael Kifer and Scott Smolka at the State Univeristy of New York, Stony Brook. Like
Nachos, OSP 2 has hardware simulation and operating system components. The hardware
in OSP 2 is simulated through a collection of methods in Java. There is no specific
hardware simulated due to the methods’ representation of a computer and there is no
assembly code executed. Because there is no assembly code to be executed, OSP 2 does
not run binary programs. The Event Engine attempts to imitate a set of binaries by
generating the appropriate operating system calls. However, this imitation is not
deterministic.
OSP 2 is more tailored to course instruction than Nachos. All student
implementation is executed from within the Interface Layer. The Interface Layer checks
the state of the system before and after student code is executed. For instance, if a thread
is not preempted at the appropriate time the Interface Layer halts the execution of OSP 2
to tell the student that his or her implementation did not implement a particular method
correctly. The Interface Layer is one of many features that allows a student to understand
each component of an operating system. Another key feature in student debugging is the
generous log file stored by OSP 2. Each hardware and software event is logged to this
file. Therefore, a student debugging code can read the log to understand the state of the
operating system that led to an error.
Beyond the rich debugging environment of OSP 2 lies a graphical configuration
for testing. When OSP 2 is run with student code, a graphical setup allows control over
parts of the Event Engine. The frequency of events that occur can be adjusted. Even the
type of event can be controlled. The percent of memory accesses that are reads or writes
may be specified during setup. The length of the test in tick may be specified. The
average and maximum numbers of tasks and threads per task is specified in the OSP 2
GUI. Once configuration is completed, the settings may even be stored as a file. While
the OSP 2 code test is running, the student can view the frequency of each event. The
most important segments of the log file are displayed as events occur, such as error
messages and system traces.
OSP 2 is easy to use from an instructor’s perspective as well. The instructor’s
package contains a system to generate projects. A professor simply chooses one of the
modules for the student to implement. The Project Generator creates skeleton code for the
assignment and a Java archive containing all code not contained in the assignment. These
two pieces to each assignment is nearly everything a student needs to complete the task.
Beyond the Project Generator, the instructor’s package comes with an Automatic Project
Submission System. The automatic submission system requires a web server supporting
Java servlets. The system allows students to submit an assignment until a deadline
determined by the instructor. It actually executes OSP 2 on the server with the student
code to validate the code. The Automatic Project Submission System is a very complete
utility necessary to teaching large numbers of students.
OSP 2 is a very valuable package for operating systems courses. It helps both
students and professors through ease of use. Although the operating system implemented
by students with OSP 2 cannot execute code, it allows students to program crucial
components in an operating system. After implementing the projects of OSP 2, a student
would be able to write his or her own operating system in Java. For a concise manual on
OSP 2, refer to the Appendix.
Conclusion
Programming is a crucial component to a student’s understanding of theories. In
particular, operating systems courses have great potential to benefit from instructional
programming environments such as Nachos and OSP 2. Nachos is more suited for a
graduate program emphasizing C or C++. OSP 2 is best suited for an undergraduate
operating systems course in a school emphasizing Java for programming.
References
Kifer, Michael and Scott Smolka. “OSP – An Environment for Operating Systems
Projects.” www.cs.sunysb.edu/~sas/courses/cse306/ spr02/project/manual.pdf
Silberschatz, A., P. Galvin, and G. Gagne. “Operating Systems Concepts: Sixth Edition”
Wiley, John & Sons, 2001.
Appendix: OSP 2 Guide
Overview
OSP/2 in an environment for students to put knowledge from an operating
systems course into practice using Java. It can logically be viewed as two parts: machine
simulation and the operating system. OSP/2 simulates a machine through a collection of
classes to represent hardware. OSP/2 is not actually executing code, but making system
calls. This leads to one of the main distinctions between OSP/2 and Nachos; Nachos
emulates a MIPS machine, so that the user can actually execute MIPS binaries, whereas
OSP/2 runs with a semi-random set of system calls to test the operating system. These
system calls are generated by the Event Engine and are intended to imitate a stream of
executing code. OSP/2 does not run applications.
OSP/2 has five different components to the operating system: Tasks, Threads,
Memory, File System, Devices, and Ports. Each component has a corresponding student
project. Each project is generated using the OSP/2 instructor’s package. The package
generates a JAR file containing all classes that the student is not implementing (OSP.jar).
Templates of the classes for the student to write are generated. The templates contain
comments, which could be enough for the student to complete his or her assignment.
Student Assignments
The student is responsible for implementing a handful of classes for each project.
He or she is given the skeleton code for each class and comments describing the content
of each method.
Nearly all of the methods in the student’s code have the prefix “do_”. This
convention is necessary to support OSP/2’s Interface Layer (IFL). You will notice that
each class extends (is a subclass of) a class with the prefix “Ifl”. The classes of prefix
“Ifl” make up the Interface Layer. The purpose of the IFL is to ensure that the student’s
implementation of code is performing correctly. Getting back to the “do_” prefix in
nearly all methods… All “do_” methods have an equivalent method in the IFL. For
example, “do_create()” in class ThreadCB has the corresponding method “create()” in
class IflThreadCB. OSP/2 only makes calls to the methods of the IFL. So OSP/2 will call
“create()” on an object of class ThreadCB. The method is inherited from IflThreadCB. It
serves as a wrapper around the method “do_create()” and checks to see that a new thread
is created correctly.
Actually Getting Work Done
All this is nice and all, but what you really want is to see the system in action,
right? The first thing you need is a student assignment directory. It should contain
“Demo.jar”, “OSP.jar”, “Makefile”, “Misc/params.osp”, “Misc/wgui.rdl”, and a few java
source files.
You may note that OSP/2 is a graphical application that uses the Java Swing
libraries. This doesn’t matter at all if you are sitting at a UNIX box with Java 1.2 or
higher.
If you’re on a UNIX platform, you’ll be using the “make” utility to get stuff done.
To see the demonstration of OSP/2 in action, run the command “make demo”.
The demonstration is just a version without any student classes; all classes are completely
implemented. You might want to play around with the settings to see what each option
does.
To work with student code, run “make” to compile code and run “make run” to
execute your code. If you would like to use the Java debugger (jdb), run “make debug”
instead of “make run”. However, be aware that executing code through the Java debugger
is much slower.
Periodically, you may want to delete your class files to feel certain that you are
compiling fresh code. To clean up your files (remove class files), run “make clean”.
Log files, schmog files
Now I’m really starting to sound like one of those Dummies books, aren’t I?
OSP/2 outputs a log file each time you run a simulation stored in “OSP.log”. The
log is most helpful when you are trying to determine errors in your code. The first section
of the log contains a little legend to explain the abbreviations used throughout the log. If
you intend to read through the log, you might want to memorize this legend or print it and
keep it handy.
The first number of each line description is the time. Time in OSP/2 is measured
in “ticks”. The calling class is also included in the line. The next line, which is indented,
contains the message describing the action of the system.
You may find that you want to write your own debugging messages. The simplest
way of writing your own debugging messages is to call
MyOut.print(String, String);
The first argument should be this if called from a non-static method or the class
name for a static method. The second argument is your message that you would like to
appear in the OSP/2 log.
Projects
A brief description of the work to be completed for each project is included.
Tasks
The tasks project is about handling tasks, also called processes. The only class to
implement is TaskCB, the class representing a task. The code handles creation and
destruction of a task.
Threads
The threads project is for handling threads. This not only includes creation and
destruction of threads, but also includes scheduling and suspension of threads. Nearly all
code is in the class ThreadCB. The class TimerInterruptHandler must also be
implemented. The ThreadCB class implements a thread control block, containing
instance methods to suspend, resume, and destroy a thread. It also contains static methods
to create a new thread and dispatch a thread. The TimerInterruptHandler class handles
timer interrupts.
Memory
The memory project involves implementing the memory management unit (MMU). The
primary goals are to lookup a memory address, process the page and frame table, and
handle page faults. The five classes to implement are MMU, FrameTableEntry,
PageTableEntry, PageTable, and PageFaultHandler. MMU handles memory references.
It must set up the frame table. FrameTableEntry is an entry in the frame table.
PageTableEntry is an entry in the page table. The PageTable class simply sets up a page
table. The PageFaultHandler class performs the appropriate swap-in and the swap-out if
needed.
Devices
The devices project implements the device driver and basic I/O control. The three classes
to implement are Device, IORB, and DiskInterruptHandler. Device schedules requests.
IORB is the input/output request block. DiskInterruptHandler handles disk interrupts.
File System
The file system project provides a layer of file handling between the user and the disk.
There are five classes to implement: MountTable, Inode, DirectoryEntry, OpenFile, and
FileSys.
Ports
The ports project implements the interprocess communication supported by OSP 2.
Messages are passed between threads using ports. There are only two classes to
implement: Message and PortCB. Message describes the structure of a message and
PortCB implements functions called by threads to pass messages.