The project has four phases, corresponding to four 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, we have structured the assignments 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 network of MIPS-like workstations. 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 our 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 covers the parts of C++ that you will need to know.
The project is to be done in teams of two or three students. The assignments will be the same for either size team. Groups of three will have less coding to do per person but will also have to manage the interactions between more people. We will not allow any groups of one.
Management of group dynamics is part of this course. No team will be allowed to dissolve unless all members can immediately join 2-3 person teams. Teams share project grades equally. If any team violates the USC code of Academic Integrity, the entire team will suffer the consequences. Play well with others.
We will use flexible slip dates for the assignments. Each team is given an automatic extension of 4 calendar days, which you can use on any assignment during the semester, in any increment, as long as the total amount of lateness did not add up to more than 4 days. For instance, you can hand in one assignment 4 days late, or each of four assignments 1 day late. This should let you schedule due dates around the due dates for other courses. When you hand in an assignment, you must identify at the top of the assignment, (i) how late this assignment is, and (ii) how much of the total slip time you have left.
After you have used up your slip time, any assignment handed in late will be marked off 10% per day. There will be no extensions granted.
The first step in doing the assignments is retrieve the Nachos sources tar file from the course's home page. This directory contains source code for Nachos for each assignment, in directories `threads, userprog, vm, filesys, network', plus code for the machine emulation, in directory `machine'. For the assignments, you will need to make changes to files in `threads, userprog, vm, filesys, network', but you may not to modify the files in the `machine' directory.
Also, so we can tell what changes you have made, you must surround every piece of code you modify with:
#ifdef CHANGED put your changes here #endif
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: