Assigned: September 7, 2005 Due: October 4, 2005 11:59:59 PM1. Objectives: To enhance Nachos application interface by adding a file system application programming interface (API). This API will include a set of system calls that will allow programmatic calls to Nachos file system from a C application program.2. Project Description:Read and understand components and architecture of Nachos system. See detailed documentation available in Nachos Roadmap. Section 5 of roadmap has details about Nachos implementation of file system. The code for the file systems can be found in the directory nachos-3.4/code/filesys. We have given below a class diagram that shows the various classes and the relationship among them.2.1 Understand the Code2.2 Design of File Syscall API3. Documentation4. Deliverables and gradingWhen you complete your project, remove all executables and object files. If you want me to read a message with your code, create a README.NOW file and place it in the nachos code directory. Tar and compress the code, and submit the file using the online submission system. It is important that you follow the design guidelines presented for the system calls. We will be running my own shells and test programs against your code to determine how accurately you designed your lab, and how robust your answers are. Grading for the implementation portion will depend on how robust and how accurate your solution is. 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.Project #1 – Implementing File-System APIIntroduction to Operating Systems CSE421/521Assigned: September 7, 2005 Due: October 4, 2005 11:59:59 PM1. Objectives: To enhance Nachos application interface by adding a file system application programming interface(API). This API will include a set of system calls that will allow programmatic calls to Nachos file system from aC application program.2. Project Description:Read and understand components and architecture of Nachos system. See detailed documentation available inNachos Roadmap. Section 5 of roadmap has details about Nachos implementation of file system. The code for thefile systems can be found in the directory nachos-3.4/code/filesys. We have given below a class diagram thatshows the various classes and the relationship among them.DirectoryEntry FileHeaderDirectory OpenFileFileSystemSystem (nachos )Figure 1: Nachos File System (nachos-3.4/code/filesys/)Figure 1 shows nachos system (code/threads/system.h, system.cc) instantiating an object of FileSystem class.FileSystem maintains all openfiles (OpenFile objects). A directory object has an Openfile object. It also has atable of objects of DirectoryEntry. All the methods such as read and write defined in the classes are accessible atkernel level and not at application level. The current Nachos file system is implemented by directly making thecorresponding calls to the UNIX file system. The API you build will facilitate operations such as creation,reading, writing, seeking into and deletion of different types of files from an application program. To accomplishthis you will make use of the classes nachos provides.2.1 Understand the CodeThe first step is to read and understand the existing code. After you expand the tar distribution of nachos, examinethe code directory. Then “gmake all” from the code directory to carry out a preliminary compile and link of codein 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 andask 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 thatparticular run. Examine the following files to understand Nachos:code/userprogsyscall.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/machinemachine.* emulates part of the machine that executes user programs: main memory, processor registers, etc.mipssim.cc emulates the integer instruction set of a MIPS R2/3000 processor.1console.* 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/threadsthread.* 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/filesysopenfile.h a 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
View Full Document
Unlocking...