Department of Computer and Information Science (IDA)

NACHOS Laboratory Assignment 2: System Calls

Overview

This assignment covers:

• System calls.
• An introduction to user programs in NACHOS.
• An introduction to user memory versus kernel memory in NACHOS.
• Making user programs.
• Using synchronization to enforce kernel functions and data structures.
• Input/output management

In the last assignment you did (#1), your test program resided in the kernel's memory (the memory of the UNIX process). This is, however, not the normal situation. An operating system must be able to run user programs, each with their own memory. The kernel should execute each user program in "user mode" instead of "kernel mode" in order to protect the kernel from the user.

The communication between the user program and the kernel is done by system calls. System calls are functions, called from the user program to the kernel. Real computers often use interrupts to accomplish that switch from user code to system code, and so does a real MIPS computer. The MIPS processor even has a special instruction called SysCall which does this.

In this assignment you will write the OS part of system calls, the hardware parts (interrupts etc.) have been taken care of, except for one thing, see below.

Examples of system calls are:

• Open - opens a file.
• Close - closes a file.
• Read - reads from a file.
• Write - writes to a file.
• Exit - exits the current thread.
• Halt - halts the processor.

The following are also system calls, but will not be required until lab #3: Memory Management where you will have several processes in memory at the same time.

• Exec - loads a program into memory and executes it in its own thread or process.
• Join - Waits for a child process to exit and returns its exit status.

Preparation

• Examine how the exception handling is implemented
• in machine/mipssim.cc (search for "RaiseException")
• in machine/machine.cc (Machine::RaiseException)
• in userprog/exception.cc (ExceptionHandler)
• Read the file userprog/syscall.h to see the prototypes of the system calls.

Answer these questions before starting with the assignment:

1. Explain step by step what happens (which code is executed in which file) when the MIPS emulator encounters a SYSCALL instruction.
2. When a user program executes a system call like Open(), an address to a string containing the filename is sent. In which memory is this string stored, and how can kernel programs access this memory (in NACHOS, i.e. with emulated hardware)?
3. When a file is opened, a file id is returned to the user program, which is used to refer to a specific opened file when doing file operations. Explain how to generate file identifiers and map them to OpenFile objects that are created in the kernel?

The NACHOS framework

NACHOS simulates a MIPS computer. In this assignment you will be using real user mode programs, that execute system calls. When running the MIPS emulator, one instruction executes at a time (the member function OneInstruction). If the instruction is a system call (an interrupt) an exception is generated. Exceptions occur when the normal program flow cannot continue for some reason (addressing error, arithmetic error etc.). A system call is one such case, and a SyscallException causes the user program to stop and kernel code to start executing. it simulates this by using a C++ feature called an exception, that is somewhat similar to an interrupt, but as software. When an exception (interrupt) occurs, the exception handler function is called (see the file exception.cc).

Shortly: A system call causes an exception, that causes the processor to go into kernel mode and jump to an exception handler. The exception handler is the entrance to the kernel. All communications with the kernel must go through it. This is a quite realistic simulation, the hardware MIPS simulation hands over the control to the software OS simulation (that's you) at the exception handler.

The exception handler must then determine what has happened (what kind of exception: syscall, memory fault, etc.) and how to handle it. In this case, the exception handler must determine which system function was requested, and execute that function. Read the code and A Roadmap Through Nachos, section 4.3

One thing you must be aware of: The MIPS machine will experience the system call as an interrupt in the middle of processing an instruction (the syscall that caused the interrupt). This means that that program counter (PC) will not be updated before the exception handler is called. When the exception handler function returns, the MIPS emulator will start from the top, and read the instruction at the PC. Before you let the exception handler function return, you must simulate a Return from interrupt instruction, updating the PC if necessary. This is very well explained in A Roadmap Through Nachos, section 6.3.

Since we now can run user programs, input/output becomes very interesting. Presumably, you want to do I/O in your userprogram to disk but also to the console. User programs are written in ordinary C (more on that later), but cannot use the standard printf() function etc. to write to the screen. When a user program starts up, it should have two open files, representing keyboard input and display output (in UNIX terms, stdin and stdout). The system calls Read and Write should be able to act directly on these, without first opening these files. The data should be routed to/from the Console device, see A Roadmap Through Nachos, section 2.5.

In this assignment you don't have to worry about files. NACHOS uses a stub file system, so that you can read UNIX files directly.

Making user programs

The user programs running in NACHOS should be compiled to MIPS machine code. Some examples of user programs can be found in the directory "test". User programs are compiled with a cross-compiler in NACHOS, compiling to MIPS machinecode. A cross-compiler is a compiler that runs on one machine, producing code for another.

There is a cross-compiler provided for you in the directory /sw/nachos/gnumips/decstation-ultrix/bin/. Some test programs already exist, including halt. There is source code for some more tests in the directory test. You will have to update the Makefile in that directory so that the CC variable points to the cross compiler. If you have problems compiling, you may have to modify the Makefile so that the GCCDIR points to the directory /sw/nachos/gnumips/decstation-ultrix/bin/. The LD and AS variables must also be redirected.

Write all your test programs in the "test" directory, and add the following lines at the end of the Makefile in order to compile the test programs correctly:

%:%.c start.o
	$(CC) $(CFLAGS) -c $<
	$(LD) $(LDFLAGS) start.o $*.o -o $*.coff
	../bin/coff2noff $*.coff $@	

Remark: the spaces at the begining of the lines correspond to a single tabulation. Or, if you prefere, you can simply copy the lines for the halt program in the Makefile and update in consequence.

Observe that the program coff2noff is called, to change the object format from the Unix format (coff) to the format used in NACHOS (noff).

After compilation, the program is linked with the assembler file start.s (actually the compiled version of start.s), that contains routines for all system calls. The assembler routine puts the arguments to the system calls in the right registers, and then generates an exception, thus performing the actual call.

Files

The working directory for this lab is the code/userprog directory.

The following files are the central files for this assignment:

• userprog/exception.cc
  Contains the ExceptionHandler()-function.
• userprog/syscall.h
  Contains the definitions of the system calls, as seen from the user process. Also holds the constants for the different system calls.

The following files are necessary to read in order to understand how NACHOS operates:

• userprog/progtest.cc
  Loads a user program into memory and starts executing it.
• threads/main.cc
  Read it again to understand how to run NACHOS with a user program.
• machine/machine.h, machine/machine.cc
  Read it to understand how the MIPS emulator works.

For an example of a test program for this laboration have a look at lab2test.c .

Assignment in detail

The assignment is to implement the following system calls:

• Halt()
• Exit(int status)
• Create(char *filename)
• OpenFileIdf Open(char *filename)
• Int Read(char *buffer,int size,OpenFileId file)
• Write(char *buffer,int size, OpenFileId file)
• Close(OpenFileId file)

Exception handler function will be used a lot in the following assignments you should rewrite the switching of exception type and system call to make future expansion easier.

You need to implement some additional functions and data structures that are not specified here, and which you must think of yourself. This is part of the assignment.

As for console I/O, in syscall.h there are two constants, ConsoleInput and ConsoleOutput that define the FileOpenId:s used with Read() and Write() to do console I/O.

Please note:

• The functions must be thread safe, e.g. employ synchronization techniques. For this assignment, only one program can reside in memory at a time, but for assignment 3 and later, multiprogramming can be used, and then the system calls must be able to handle that.
• You make these system calls available for NACHOS user processes. Your implementations of these functions inside the kernel can take parameters of your choice.
• All parameters to a system call must be taken from the registers, using machine->ReadRegister(). If the parameter is a pointer into the userprograms memory, as for instance when calling open, it is crucial to get the value from the user memory into the kernel memory by using the method machine->ReadMem(). If this is forgotten, you will surely get a segmentation fault (at least in the next lab assignment).

It is strongly recommended that you put kernel functions in a separate module (file), to avoid cluttering up the exceptions.cc file. You should also move the halt system call there.

Running and debugging

This lab assignment is hard to debug without a debugger, in fact, in order to get help from the lab assistants you will have to use one. There is a debugger called "ddd" available which works fine with NACHOS. It is a graphical interface on top of the "gdb" (the GNU debugger).

You can call it by:

       ddd ./nachos

To run a user program you must provide some options. Read the threads/main.cc file, section userprog, to find out which options to use. Read the ddd manual to find out how to run nachos with options from within ddd.

Helpful Information

Next Laboratory work

Laboratory Assignment 3