2.5 Project 6: implementing file-system api  (Page 2/3)

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:

1. In userprog/syscall.h file, define a code for the system call, and add the C function prototype corresponding to the system call. (Remember it is C language interface).
2. In start.s add a “macro” stub corresponding to the syscall. This is a set of assembly language instructions and directives that will help compiler substitute the C call with this stub code. See start.s for examples.
3. ExceptonHandler function in exception.cc provides the entry point into kernel for handling the system call. Add the code for exception handler for the new syscall to exception.cc.
4. If you added any new supporting classes in userprog, include them Makefile.common definitions for USERPROG_H, USERPROG_C, and USERPROG_O.
5. Add a C test program (say, trial1.c) that uses this system and change Makefile in test directory to compile and link it. See examples in the current Makefile in the test directory. “gmake”
6. “gmake” in userprog and test the new system call by executing: nachos –rs 5678 –x ../test/trial1

Design of file syscall api

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.