<< Chapter < Page Chapter >> Page >

For console read and write, you will use the SynchConsole class, instantiated through the gSynchConsole 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)

For file read and write, you will use the supplied classes in file system. You will use the default filesystem behaviors, however, you will return the same type of return values as for synchconsole. Both read and write will return the actual number of characters read and written. Both system calls will return –1 for failure. Read and write for files will use binary data for input and output.

  • Implement the int Seek(int pos, OpenFileID id) system call. Seek will move the file cursor to a specified location. The parameter pos will be the absolute character position within a file. If pos is a –1, the position will be moved to the end of file. The system call will return the actual file position upon success, -1 if the call fails. Seeks on console IO will fail.
  • Implement a createfile user program to test the createfile system call. You are not going to pass command line arguments to the call, so you will have to either use a fixed filename, or prompt the user for one when you have console IO working.
  • Implement a help user program. All help does is it prints a list to standard output of all the user programs you are going to create or have created in the test directory. Help should list each program and a brief 1 line description of each program. (NOTE: This is nothing fancy, just calls using the Write() system call to standard output.)
  • Implement an echo user program. For each line of input from the console, the line gets echoed back to the console.
  • Implement a cat user program. Ask for a filename, and display the contents of the file to the console.
  • Implement a copy user program. Ask for a source and destination filename and copy the file.
  • Implement a reverse user program. This program asks for a source and destination file, takes input from the source file, reverses the source file and writes it to the destination.
  • Implement encrypt that will take a simple character input file and create a new encrypted file.
  • Implement decrypt that take an encrypted file and create a new decrypted file.
  • Implement any other tests you feel are necessary to ensure the correctness of your solution. BIG HINT: Implement tests to cover some of the things we changed that are not tested by parts h through m.

NOTE: A large portion of your grade will depend not only on the correctness of your implementation but how accurately your code conforms to the system call specifications presented in this document. As we are building a robust operating system, the user should not be able to perform any system call that will crash Nachos. The worse case scenario is that the user program might generate a Nachos runtime exception, which you will be handling within part a.

Phase 4: [10%] documentation

This includes internal documentation (comments) and a BRIEF, BUT COMPLETE external document (read as: paper) describing what you did to the code and why you made your choices. Everybody needs to demo their project (whether completed or not) to Teaching Assistants (TAs) to get a grade for the project. Demonstration times will be posted after the due date. Submit the documentation online on the due date and take a hardcopy with when you demo the project to the TA for grading. DO NOT PARAPHRASE THIS LAB DESCRIPTION AND DO NOT TURN IN A PRINTOUT OF YOUR CODE AS THE EXTERNAL DOCUMENTATION

Deliverables and grading

When 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. I 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.

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