Project Overview: Nachos

The 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, we give you a very simple, but functional, operating system called Nachos (Not Another Completely Heuristic Operating System). Over the course of the semester, your job will be to improve the functionality and performance of Nachos; we expect that you will eventually modify or replace much of the what you start out with.

The project has four phases, corresponding to four major pieces of a modern operating system: thread management, multiprogramming, file systems, and networking.

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.

The end result of the project is to build a distributed application, for instance, a game such as ``tic-tac-toe'' or ``battleship'', with each player on a different computer connected by a network. But! before you do this, you have to build the operating system that the distributed application needs in order to be able to run, that is, you have to build the infrastructure for running distributed programs.

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 a debugger 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 3, 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 (present in the machine directory) , although you are permitted to change any of the Nachos code that runs on top of the emulation.

Project Mechanics

• 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.
• Team members will all receive the same grade for each assignment.
• We will use flexible slip dates for the assignments. Each team is given an automatic extension of 6 calendar days, which you can use on any assignment during the semester, in any increment (up to 4 on any single assignment), as long as the total amount of lateness did not add up to more than 6 days. For instance, you can hand in one assignment 4 days late, and another assignment 2 days late, or some other combination that adds up to 6. There is no bonus for not using slip days. This should let you schedule due dates around the due dates for other courses.
• 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.

Getting Started

The first step in doing the assignments is retrieve the Nachos sources tar file from the assignment home page. This directory contains source code for Nachos for each assignment, in directories `threads, userprog, 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, filesys, network', but you should not need to modify the files in the `machine' directory.

Modifying Code

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:

• Read the code that is handed out with the assignment first, until you pretty much understand it. Start with the ``.h'' files.
• Don't code until you understand what you are doing. Design, design, design first. Only then split up what each of you will code.
• Talk to as many other people as possible. CS is learned by talking to others, not by reading, or so it seems to me now.