跳转到内容

Nachos 2014

来自ACM Class Wiki

News

  • (Sep 26) Setup web page.

Overview

The project for this course is to build an operating system based on Nachos, which is a very simple, but functional, operating system emulated on Java Virtual Machine. Over the course of the semester, your job will be to complete the functionality and improve the performance of Nachos.

The end result of the project is to build the infrastructure for running multiple user-defined programs. Part of the code we provide is a software emulation of a MIPS-like workstation. For instance, our code emulates turning on and off interrupts, taking exceptions and page faults, as well as the actions of physical devices (e.g. a disk, a console, etc.).

It is important to realize that while we run Nachos on top of this emulation as a Java program, the code you write and most of the code we provide are exactly the same as if Nachos were running on bare hardware. We run Nachos as a Java program for convenience: it is very portable and easier to debug. These same reasons apply in industry; it is usually a good idea to test out system code in a simulated environment before running it on potentially flaky hardware.

The project has several phases, corresponding to the major pieces of a modern operating system: thread management, multiprogramming, virtual memory, file system, etc. Some phases build on previous phases; for example, all parts of the project use thread management routines. Part of the charm of building operating systems is that you get to "use what you build": if you do a good job in designing and implementing the early phases of the project, that will simplify your task in building later phases.

Unless you work for a really smart company, when you develop operating system software you usually cannot change the hardware to make your life easier. Thus, you are not permitted to change any of our emulation code, although you are permitted to change most of the Nachos code that runs on top of the emulation.

Finally, some suggestions for doing well in this course:

  • Read the code that is handed out with the assignment first, until you pretty much understand it. Start with the interface documentation.
  • Don't code until you understand what you are doing. Design, design, and design first.
  • If you get stuck, talk to as many other people as possible.

Syllabus

Grading Policy

Raw Grade

For each phase, we will use a set of test cases to see if your implementation achieves the expected behavior within a limited time (varied for each case). You will be graded according to the number of test cases passed. The percentage for each phase is:

  • Phase 1: 30%
  • Phase 2: 20%
  • Phase 3: 30%
  • Phase 5: 20%

You can submit your work no later than 3 days past the deadline, and you can submit for multiple times. The penalty for the delayed submissions and re-submissions is calculated as follows: 

           / D(D+1)            \
Penalty = ( ------- + (R-1) x 5 ) %
           \   2               /

where D is the number of days past the deadline and R is the number of the submitted versions. Your final grade will be the maximum of the grades of all the submissions you make. However, we may choose not to grade your submission if the maximum potential grade of that submission cannot surpass the current one.

The result for each phase will be published as soon as possible, no later than one week after the deadline. To help with your debugging, the full test cases used for grading will be published at the 3rd day past the deadline.

Final Grade

Final grade will be your raw grade multiplied by the penalty ratio from your code review result. In the code review phase, you need to show your understanding of the project and your code. A penalty will be made when we are not convinced that you are very familiar with your own code or don't fully understand what you are doing during the project.

Warning

Any cheating submission will receive a score of zero. Please note that the following actions will also be treated as cheating.

  1. Do not directly use Java threads (the java.lang.Thread class). The Nachos security manager will not permit it. All the threads you use should be managed by TCB objects (see the documentation for nachos.machine.TCB).
  2. Do not use the synchronized keyword in any of your code. We will grep for it and reject any submission that contains it.
  3. Do not directly use Java File objects (in the java.io package). In later projects, when we start dealing with files, you will use a Nachos file system layer. When you want to add source files to your project, simply add entries to your Makefile.

Auto Grading

Your project code will be automatically graded. There are two reasons for this:

  • An autograder can test your code a lot more thoroughly than a TA can, yielding more fair results.
  • An autograder can test your code a lot faster than a TA can.

Of course, there is a downside. Everything that will be tested needs to have a standard interface that the autograder can use, leaving slightly less room for you to be creative. Your code must strictly follow these interfaces (the documented *Interface classes).

In order for you to verify that your code is compatible with the autograder, there are some simple compatibility tests you can run before you submit.

Since your submissions will be processed by a program, there are some very important things you must do, as well as things you must not do.

For all of the projects in this course...

  1. Do not depend on Makefile. javac automatically finds source files to compile, so we don't need you to submit Makefile.
  2. Do not rely on any additional keys being in conf file, you will not be submitting this file either. Only modify conf files according to the project specifications.
  3. Do not modify any classes in the nachos.machine package, the nachos.ag package, or the nachos.security package. You will not be submitting any of these classes.
  4. Do not add any new packages to your project. All the classes you submit must reside in the packages we provide.
  5. Do not modify the API for methods that the autograder uses. This is enforced every time you run Nachos by Machine.checkUserClasses(). If an assertion fails there, you'll know you've modified an interface that needs to stay the way it was given to you.

Submission Guideline

Preparation

  1. Create a Bitbucket account and a private git repository nachos2014
  2. Add username Hareran to your repository with read permission
  3. Get the Nachos framework from https://bitbucket.org/xjia/nachos-framework/src

Refer to Bitbucket 101 on how to install git and how to create accounts and repos, etc.

Warning: You must create a private repository so others cannot access your code. If you share code with others, you will get a score of zero for this course.

Repository Layout

If your project is located at e.g. /home/yourname/nachos2014 (or C:\Users\yourname\nachos2014), the layout of this directory should be as follows. 

nachos2014
|-- nachos-sjtu
|   |-- conf
|   |-- doc
|   |-- src
|   |   |-- nachos
|   |       |-- ag
|   |       |-- filesys
|   |       |-- machine
|   |       |-- network
|   |       |-- security
|   |       |-- threads
|   |       |-- userprog
|   |       \-- vm
|   |
|   |-- README
|   \-- .gitignore
|
\-- test

You must put your Java source code files in the src directory. It is recommended to create the .gitignore file with the following content. 

bin/
*.class

Submit

This course project is divided into four phases, and you are required to submit by creating a tag for each of the phases.

By typing the following commands, you can submit the second version (v2) of your code for an imaginary phase 0 (p0). 

git tag p0v2
git push --tags

For the real phases 1, 2, 3 and 5, use p1, p2, p3 and p5 instead of p0. Start versioning your submission from v1.

Resources

Contacts

Xuezhi Cao a9108g [at] gmail.com
Zhiming Zhou heyohaizhou [at] gmail.com
Guanru Li lgr150 [at] sjtu.edu.cn
Haoran Wang hrwangchengdu [at] hotmail.com
Min Wang yinger650 [at] gmail.com
检索自“https://acm.sjtu.edu.cn/w/index.php?title=Nachos_2014&oldid=1910”