The first step is to read and understand the existing code. After you expand the tar distribution of nachos, examine the code directory. Then “gmake all” from the code directory to carry out a preliminary compile and link of code in all the directories. Makes sure compilation finishes without errors. (Get help from TAs in case you have errors.) There is a trivial test provided with the distribution code/test directory, ‘halt’; all halt does is to turn around and ask the operating system to shut the machine down. Change directory into userprog directory. Run the command ‘nachos –rs 1023 -x ../test/halt’. This should halt the simulated MIPS machine and type out statistics for that particular run.

Examine the following files to understand Nachos:

code/userprog

syscall.h: This provides the code and function prototype for system calls that user level test programs can invoke.

exception.cc: The handler for system calls and other user-level exceptions, such as page faults. Currently only the ‘halt’ system call is supported.

code/machine

machine.*emulates part of the machine that executes user programs: main memory, processor registers, etc.

mipssim.ccemulates the integer instruction set of a MIPS R2/3000 processor.

console.*emulates a terminal device using UNIX files. A terminal is (i) byte oriented, (ii)incoming bytes can be read and written at the same time, and (iii) bytes arrive asynchronously (as a result of user keystrokes), without being explicitly requested.

code/threads

thread.* implements thread (unit of work) for nachos. Methods to control operation of threads. All the thread specific (local) properties are define here.

system.* implements all the system facilities. The common (global) components of the machine are declared, instantiated here. For example, FileSystem object, currentThread object (pointer to current thread), etc.

synchconsole.* routine to synchronize lines of I/O in Nachos. Use the synchconsole class to ensure that your lines of text from your programs are not intermixed.

code/test/*C programs that will be cross-compiled to MIPS and run in Nachos; start.s has all the assembly language stubs for the system calls.

code/filesys

openfile.ha stub defining the Nachos file system routines.

Read the Makefile in the various directories. In general, while working on Nachos projects you will add classes (your code) to userprog and C programs to test directory. You may modify existing classes in other directories.

The following are the steps in adding and testing a new system call to Nachos:

In order to fully realize how an operating system works, it is important to understand the distinction between kernel (system space) and user space. If we remember from class, each process in a system has its own local information, including program counters, registers, stack pointers, and file system handles. Although the user program has access to many of the local pieces of information, the operating system controls the access. The operating system is responsible for ensuring that any user program request to the kernel does not cause the operating system to crash. The transfer of control from the user level program to the system call occurs through the use of a “system call” or “software interrupt/trap”. Before invoking the transfer from the user to the kernel, any information that needs to be transferred from the user program to the system call must be loaded into the registers of the CPU. For pass by value items, this process merely involves placing the value into the register. For pass by reference items, the value placed into the register is known as a “user space pointer”. Since the user space pointer has no meaning to the kernel, we will have to translate the contents of the user space into the kernel such that we can manipulate the information. When returning information from a system call to the user space, information must be placed in the CPU registers to indicate either the success of the system call or the appropriate return value.

Our simulator can run normal programs compiled from C -- see the Makefile in the ‘test’ subdirectory for an example. The compiled programs must be linked with some special flags, then converted into Nachos format, using the program “coff2noff” (in bin directory). Floating-point operations are not supported.

Implement exception handling and handle the basic system calls for file system. Figure 2 depicts the role of file syscall API.

Figure 2

Figure 2: File Sys Call Interface between a user program and Nachos kernel

Signatures of the file system call API are given below. Implement the signatures exactly as given here. OpenFileID is integer type.

Figure 3

You will need to do the following steps:

For console read and write, you will use the SynchConsole class (code/threads directory), instantiated through the gSynchConsole global variable (see threads/system.h,.cc). You will use the default SynchConsole behaviors for read and write, however you will be responsible for returning the correct types of values to the user. Read and write to Console will return the number of characters read or written. In the case of read or write failure to console, the return value should be –1. If an end of file is reached for a read operation from the console, the return value should be –2. End of file from the console is returned when the user types in Control-A. Read and write for console will use ASCII data for input and output. (Remember, ASCII data is NULL (\0) terminated). Also for file types RO and RW use ASCII reads, and for RX use BINARY read and write.

NOTE: A large portion of your grade will depend not only on the correctness of your implementation but how accurately your code conforms to the system call specifications presented in this document. As we are building a robust operating system, the user should not be able to perform any system call that will crash Nachos. Make sure there is a default case in the exception handler that will print out a message and halt the system in the case.