CS 422 Assignments
The programming project for this course is to build an operating system
from scratch. We believe that the best way for you to understand operating
systems concepts is to build a real operating system and then to experiment
with it. To help you get started, Tom Anderson of U. Washington
has built a very simple, but functional, operating system called Nachos.
Over the course of this semester, your job will be to improve the
functionality and performance of Nachos.
The project has four phases, corresponding to each of the major pieces
of a modern operating system: thread management, multiprogramming,
virtual memory, and file systems.
Some phases build on previous phases; for example, the file system
uses thread management routines.
As far as possible, the assignments are structured so that you
will be able to finish the project even if all of the pieces are not working,
but you will get more out of the project if you use your own software.
Part of the charm of building operating systems is that you get to
``use what you build'' -- if you do a good job in designing and
implementing the early phases of the project, that will simplify your
task in building later phases.
Part of the code we provide is a software emulation of a
MIPS-like workstation. For instance, our code emulates turning on
and off interrupts, taking exceptions and page faults, as well as
the actions of physical devices (e.g., a disk, a console, and a
network controller).
It is important to realize that while we run Nachos on top of this
emulation as a user program on UNIX, the code you write and most of the code
we provide are exactly the same as if Nachos were running on bare hardware.
We run Nachos as a user program for convenience: so
that we can use gdb and so that multiple students can run Nachos
at the same time on the same machine. These same reasons apply
in industry -- it is usually a good idea to test out system code
in a simulated environment before running it on potentially flaky hardware.
In order to port Nachos to real hardware, we would have to
replace our emulation code with a little bit of machine-dependent code and
some physical machines. For example, in assignment 1, we provide
routines to enable and disable interrupts; on real hardware,
these functions are provided by the CPU.
In assignment 4, we emulate the behavior of a physical disk;
disk read and write requests instead go to a UNIX file and an
interrupt is generated after some period of time.
The details of how to make disk read and write requests varies tremendously
from disk device to disk device; in practice, you would want to hide
these details behind something like the Disk abstraction that we provide.
Unless you work for a really smart company, when you develop
operating system software you usually cannot change the hardware to
make your life easier. Thus, you are not permitted to change any of
the emulation code, although you are permitted to change any of
the Nachos code that runs on top of the emulation.
Nachos is coded in a subset of C++; a separate document (in
postscript
or pdf)
covers the parts of C++ that you will need to know.
Finally, a former student had the following suggestions for doing well
in this course, and since we agree with all of them, we include them here:
The project is to be done in teams of three.
Team members will all receive the same grade
for each assignment.
There are two deadlines for each assignment:
- Design Specification: You must submit, to the TA's
mailbox, a written description of your design. The due
date for the
design specification for each assignment will be posted on the assignment
webpage. Note that you will have the
opportunity to revise this design specification before the final
submission deadline. The reason for submitting a draft
in advance of the Design Review meeting is to ensure that time spent
in the meeting is as productive as possible.
- Final Submission: On the deadline specified for the
assignment, you must submit your
project. Your submission will inclue your final design specification,
a README file, a TESTCASE file, and, of course, any source code that
you modified or added to Nachos.
Design Specifications
Your design specification should demonstrate that you have thought
about the problem and devised a plausible solution. Your solution
should be described in prose, but please use diagrams or psuedo-code
where appropriate. Clarity, concision and simplicity are virtuous;
length is not.
Your design should also include a short description of your Test
Plan. How will you test your code to be sure it is correct? Test
design is very challenging for operating systems code. Be sure that
you have designed tests that will accurately determine whether your
code works correctly, and check for edge cases.
Your design specification should be submitted in hardcopy form to the
TA's mailbox by the deadline.
Final Submission
Your final submission must include the following items:
- Final Design Specification. This should describe the
design of your final submission, and should correspond with your
implementation. This should be based on your original design, but
should reflect any changes to the design during implementation. (Of
course, if your design was flawless, then this will simply involve
re-submitting your original design specification.)
- README file. This should summarize your implementation
of the design. It should clearly state what files were changed or
added to the project, and how they were changed. If your
implementation differs from your design in any way, this should be
included in the README. If the assignment included a written
component, this should also go in the README.
- TESTCASE file. We expect you to run test cases to demonstrate that your
code works (or that it doesn't!). The results of these test
cases should be put into a TESTCASE file (along with an explanation
of what each test case is supposed to show). We are not going to tell
you what test cases to run -- it is up to you to convince us
that your code works. You should pick the minimal set of test cases
that do this.
Of course, you will also submit your Nachos sources.
Any changes that you make to the source code should be
surrounded with the the comments:
// CHANGED FOR AS1 (or 2-4)
put your changes here
// END OF CHANGES FOR AS1 (or 2-4)
This will help us quickly locate your changes when grading your submission.
Late Submissions
Each group is given 6 discretionary late days
(i.e., 144 hours) for the assignments, but any one assignment may only
be up to 4 days late. These are calendar days
not business days. These late days do not apply to
Assignment 0
which must be submitted on time.
Before work begins on assignment 1, we will have a system in place to
allow you to use RCS to share code with other members of your group,
and to submit assignments. RCS is a Revision Control System, and is
an essential tool for working with others on a team software project.
More information on RCS will be forthcoming; Watch This Space!
For Assignment 0, you should simply peruse the contents of
the directory /c/cs422/nachos/code
on any zoo machine. This directory contains source code for Nachos
for each assignment.
The source code for the various asssignments is in the subdirectories
threads, userprog, vm and
filesys. The source code for the machine emulation is in
the subdirectory machine.
For the assignments, you will need to make changes to
files in these directories,
but you should not need
to modify the files in
the `machine' directory.
Question: how to build a large software system in
a reasonable amount of time and make it work reliably?
Programming is craft: something like a high-tech form of silversmithing.
To make big systems work, it takes tremendous amount of discipline and
structure.
Summary: programming takes discipline and is a learned
craft. Take time up front to save time later. Be willing to cut your
losses.