Part 1: Syscall - KGRC199913/NachOS GitHub Wiki

NachOS School Project Wiki

PROJECT 1 – INTRODUCE OS

Project Policies:

  • Please work with team (2 students).

  • Any group has the same code will be get zero mark in practice part and fail in the final exam of this course.

How to submit your project?

Submit your project to moodle site of this course.

Please put the following in a directory with name: student_ID1 – student_ID2 (student_ID1 < student_ID2) and compress it to zip/tar/gz file:

  1. Source code NachOS after finishing the requirements in Module 3. Include your comments to briefly explain your code. Delete all execute and object file after you compile and test your source code.

  2. Final report: A word file to describe how you modified NachOS, everything you consider important (except source code). Please print your final report in demonstration day.

Deadline and Evaluation:

Deadline: following the deadline on moodle

OBJECTIVE

This project concentrates into 3 following modules:

Module 1. Research NachOS source code

The first step is to read and understand the part of the system by referring to NachOS source code. NachOS source code can run a single user-level ‘C’ program at a time. As a test case, it provided you with a trivial user program, ‘halt’; all halt does is to turn around and ask the operating system to shut the machine down.

Run the program ‘nachos –rs 1023 -x ../test/halt’. As before, trace what happens as the user program gets loaded, runs, and invokes a system call:

 protest.cc Test routines for demonstrating that NachOS can load a user program and execute it.

 syscall.h system call interface: Includes definition of NachOS system calls. These are NachOS operations that can be invoked from user programs, by trapping to kernel via the “syscall” instructions

 exception.cc There are two kinds: syscall - The user code explicity requests to call a procedure in the NachOS kernel. Exceptions - The user code does something that the CPU can’t handle.

 bitmap.* Data structures defining a bitmap – an array of bits each of which can be either on or off. Most useful for managing the allocation of elements of an array for instance, disk sectors, or main memory pages.

 filesys.h: A file system is set of files stored on disk, organized into directories. Operation on the file system have to do with naming: creating, opening, and deleting files.

 openfile.h There are two implementations. One is a STUB that directly turns the file operations into the underlying UNIX operations. The other is a real implementation, that turns these operations into read and write disk sector requests.

 translate.* Defines an entry in a translation table wither in a page table or a TLB. Each entry defines a mapping from one virtual page to one physical page

 machine.* d emulate the part of machine that execute the user program: main memory, processor register, etc.

 mipssim.cc Emulate the interger instruction set of MIPS R2/300 CPU

 console.* emulates a terminal device using UNIX files. A terminal is byte-oriented and allows incoming bytes to be read and written at the same time. Bytes arrive asynchronously –as a result of user keystrokes—without being explicitly requested.

 synchconsole.* Routine to synchronously access the console. The console itself s asynchronous. Group of functions to manage I/O by line.

 ../test/* Include the c program which is compiled into MIPS and execute in NachOS

Module 2. OS’s architechture (kernel space and system space)

In order to fully realize how an operating system works, it is important to understand the distinction between kernel (system space) and user space. 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.

Nachos gives you a simulated CPU that models a real CPU. In fact, the simulated CPU is the same as the real CPU (a MIPS chip), but we cannot just run user programs as regular UNIX processes, because we want complete control over how many instructions are executed at a time, how the address spaces work, and how interrupts and exceptions (including system calls) are handled.

Nachos provided 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”

Module 3. Implement exceptions and system calls

Refer to documents about:

 How to write a system call in NachOS

 How to add a new class to NachOS

 How a Nachos can communicate with user program

a. Alter exception.cc to handle all of system exceptions as listed in machine/machine.h Most of the exceptions listed in this file are comprised of run time errors, from which the user program will be unable to recover. The only special cases are no exception, which will return control to the operating system and syscall exception, which will handle our user system calls. For all other exceptions, the operating system should print an error message and Halt the simulation.

b. Create a control structure that can handle the various Nachos system calls. Test your control structure by re-implementing the void Halt() system call.

c. All system calls beyond Halt() will require that Nachos increment the program counter before the system call returns. If this is not properly done, Nachos will execute the system call forever. Since the MIPS emulator handles look ahead program counters, as well as normal ones, you will have to emulate the program counter increment code as found in the machine directory. You will have to copy the code into your syscall exception handler and insert it at the proper place. For now, you will have to use the Halt() system call at the end of each of your user programs.

 Use class SynchConsole to implement these following system calls:

d. int ReadInt()

Allow user to enter an integer. If user enter a wrong value different from integer, this syscall will return to zero.

e. void PrintInt(int number)

Print out an integer on screen

f. char ReadChar()

Allow user to enter a character

g. void PrintChar(char character)

Print out an integer on screen

h. void ReadString (char[] buffer, int length)

Allow user to enter a string and read this string into a buffer.

void PrintString (char[] buffer)

Print out an integer on screen.

Note:

 Remember, the buffer exists in user space. This means the buffer that the user space pointer points to must be translated from user memory space to system memory space.

 For console read and write, you will use the SynchConsole class, instantiated through the SynchConsole global variable. 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 actual number of characters read or written, not the requested number of characters. In the case of read or write failure to console, the return value should be –1. 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)

 You should increase the program counter after each of system call to prevent loop case.

i. Implement help program: print the simply introduction about your team and briefly description of sort and text program (refer to PrintString(char[]) system call).

j. Implement the text program: allow user to input a string/char (include space character) and print that string/char on screen.

k. Implement the sort program:

 Allow user entering an interger array with n elements. n is entered by user (n≤ 100)

 Use the bubble sort algorithm to sort the above array.

Note:

Remember, the user should not be able to do anything to corrupt the system, and system calls should trap as many error conditions as possible.

You must to base on your syscall (already implement in d to h) to meet the requirement in i, j, k.