<< Chapter < Page Chapter >> Page >

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”

Phase 3: [80%] exceptions and io system calls + [10%]Correct design and implementation of encrypted file types

Implement exception handling and handle the basic system calls for file IO. (All system calls are listed in syscall.h) We have provided you an assembly-language routine, ‘syscall’, to provide a way of invoking a system call from a C routine (UNIX has something similar -- try ‘man syscall’). You will need to do the following steps. NOTE : You should -NOT alter the code within the machine directory, only the code within the userprog directory.

  • 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.
  • Create a control structure that can handle the various Nachos system calls. Test your control structure by re-implementing the void Halt() system call. Make sure that this call operates in the same manner as we discussed during the Nachos walkthrough; it should cause the Nachos simulation to terminate immediately. Test the call’s accuracy with the test user program.
  • 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.
  • Implement the int CreateFile(char *name) system call. The createfile system call will use the Nachos Filesystem Object Instance to create a zero length file. Remember, the filename 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. The createfile system call returns 0 for successful completion, -1 for an error.
  • Implement the OpenFileID Open(char *name, int type) and int Close(OpenFileID id) system calls. The user program can open two types of “files”, files that can be read only and files that can be read and write. Each process will allocate a fixed size file descriptor table. For now, set this size to be 10 file descriptors. The first two file descriptors, 0 and 1, will be reserved for console input and console output respectively. The open file system call will be responsible for translating the user space buffers when necessary and allocating the appropriate kernel constructs. You will use the filesystem objects provided to you in the filesystem directory. (NOTE: We are using the FILESYSTEM_STUB code) The calls will use the Nachos Filesystem Object Instance to open and close files. The Open system call returns the file descriptor id (OpenFileID == an integer number), or –1 if the call fails. Open can fail for several reasons, such as trying to open a file or mailbox that does not exist or if there is not enough room in the file descriptor table. The type parameter will be set to 0 for a standard file and 1 for a read only file, 2 for encrypted files. Encrypted files will have modified read and writes that encrypt the content. If the type parameter is set to any other value, the system call should fail. The close system call will take a file descriptor as the parameter. The system call will return –1 on failure and 0 on success.
  • For crypto files any simple encryption /decryption scheme can be used. E.g. a separate character mapping table can be maintained that maps one character to a different character. Write method will use this mapping table for encryption and read method will use the inverse of the mapping table for decryption.
  • Implement the int Read(char *buffer, int charcount, OpenFileID id) and int Write(char *buffer, int charcount, OpenFileID id) system calls. These system calls respectively read and write to a file descriptor ID. Remember, you must translate the character buffers appropriately and you must differentiate between console IO (OpenFileID 0 and 1) and File (any other valid OpenFileID). The read and write interaction will work as follows:

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Operating systems. OpenStax CNX. Aug 13, 2009 Download for free at http://cnx.org/content/col10785/1.2
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Operating systems' conversation and receive update notifications?

Ask