COS 318: Operating systems
Fall 2004, Princeton University
Prerequisites: COS 217 and 226 or instructor's permission.
Text Book: Modern Operating Systems, 2nd Edition, Andrew S. Tanenbaum, Prentice-Hall, 2001
Grading Policies: Projects (60%), midterm (15%), quizzes (15%), and participation (10%).
9/9: Introduction (preparation reading MOS 1.1-1.2)
9/14: Overview (reading MOS 1.3-1.5)
9/16: System calls and OS structure (reading MOS 1.6-1.7)
9/21: Processes and threads (reading MOS 2.1-2.2)
Lecture notes, precept notes.
9/27: Project 1 due at 11:59pm
9/28: Preemptive scheduling and Mutex Implementation (reading MOS 2.3.3)
9/30: Semaphores (reading MOS 2.3.4-2.3.6)
10/7: CPU scheduling (reading MOS 2.5)
10/12: Deadlocks (reading MOS chapter 3)
10/14: Message passing (reading MOS 2.3.8, 8.2.1-8.2.4)
10/19: Protection and security (reading MOS chapter 9)
Guest Lecture by Professor Edward Felten
10/23-10/31: fall recess
11/2: I/O devices and drivers (reading MOS 5.1-5.3, 5.5-5.9)
11/9: Virtual memory address translation (reading MOS 4.1-4.3.3)
11/11: Virtual memory paging (reading MOS 4.4)
11/16: Virtual memory design issues (reading MOS 4.6-4.7)
11/18: Disks (reading MOS 5.4)
11/23: File systems (reading MOS 6.1 and 9.6)
11/30: File layout and Directories (reading MOS 6.2, 6.3.1-6.3.3, 6.4.3, 6.4.5)
12/2: File system performance and NFS (reading MOS 6.3.7, 10.6.3, 10.6.4)
12/7: File system reliability (reading MOS 6.3.6, 6.3.8)
1/11: Project 6 due
Students will be paired as a working group for each project. You will be regrouped after three projects in order to give you a chance to work with another person. Each project has two grading phases: design review and final submission. To conduct a graded design review, each working group or student will meet with your TA for 10 minutes one week before the project is due. The main purpose of the design review is to get you start on the projects early. Another purpose is to let you catch errors early to avoid frustrated debugging. Also, it gives you a chance to explain and defend your approach. Each student needs to prepare a short presentation to show your approach to the TA. You should pretend that you are in the real world and give your supervisors a design review presentation. My advice is to prepare one or two pages showing your data structures, interfaces, and algorithms instead of showing encrypted code. Drawing diagrams are very helpful. Your presentation should take no more than five minutes and the feedback from the TA will normally take no more than five minutes.
Note that you have to sign up for a design review session. No design review session = no grade for the design review. If you don't show up for your design review session, you'll have to make a new appointment and 10% of your design review grade will be subtracted.
The final submission will be done online, following the specific instructions in each project description. You should include a small README file with your project submission. You should concisely describe your design and implementation. Also, you need to describe what parts work and what parts don't; and how to compile and run your program (if you are not using the Makefile we provided). You don't have to repeat anything you presented in the design review. The TA who is in charge of the project will grade the project without correcting your code. It is your responsibility to figure out how to correct your code by comparing your implementations with the released solutions.
Normally, we will give the same grade to both students in a working group. If one of the students feel that the other student did more work and deserve more credits, please inform the TA who is in charge of the project by e-mail.
You will be using the Linux PCs in the 010 lab in Friends Center. There is one machine dedicated for booting your kernel so that you don't need to reboot your working environment each time you try your new kernel. All the projects will be done on a USB flash memory stick, so please do not write your kernel to the hard disk.
The computer lab in Friend 010 is available for your use. When working on the assignments, it is useful to use one PC as a development machines and another as a test machine. Please share test machines if the lab is full.
Projects will be tested on a RedHat 9.0 (gcc 3.2.2) machines, so make sure your projects compile and run properly on Redhat 9.0 (gcc 3.2.2) if you develop using other tool chains.
Project submissions are due at 11.59PM on the due date. Late submissions are marked down using a popular function. In this way, an assignment which is only a few hours late doesn't get penalized that much. A late grade is computed as follows:
grade = original_grade * exp(-time_late/three_days)
Examples: work turned in five minutes late gets 99.9% credit, one hour late gets 98.6% credit, six hours late gets 92.0% credit, one day late gets 71.7% credit, three days late gets 36.8%, and one week late gets 9.7%.
Exceptions will be made only in extreme circumstances and only in advance.
The midterm exam will be designed to test how well students understand the materials taught in the lectures as well as in the projects. Please watch the schedule of this web page for the times and the locations of the exams.
It is strongly recommended that students read the suggested reading materials before the class. A number of discussion topics will be provided on the course web page before each class starts. Students are required to turn in their notes on their thoughts about these questions at the beginning of each class. These "discussion topics" are reviewed as open-book quizzes of the class.
The participation grades will be based on the students' understanding of the discussion topics shown in their submitted notes and their contributions in the class discussions. Student will will earn 3 points each time: 3 for excellent understanding, 2 for good understanding, 1 for understanding a little, and 0 for no understanding.
You can also earn extra credits by developing useful tools for the projects that can be used by others. To do so, you need to discuss your ideas first with the instructor and the TAs.
There is a clear distinction between cooperation and cheating. Copying other's code or designs are strictly prohibited. We will punish transgressors severely.
Kai Li, COS 318