COS 318: Operating systems  

Fall 2004, Princeton University


Course Summary | Announcement | Administrative | Schedule | Resources | Policies


Course Summary

This course studies the design and implementation of operating systems. The topics include: processes, mutual exclusion, synchronization, memory management, virtual memory, processor scheduling, disk management, file systems, security, and protection.  Students will be working on a series of six projects leading to a small, real operating system.  

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%).


Announcements


Administrative Information

Lectures

Precepts

Professor

Teaching assistants

Undergraduate Coordinator

Keeping in touch


Schedule

September

October

November

December

January


Resources

Getting started

Tutorial and Documentation


Policies

Grading

The course grades will be determined roughly as follows: The course will not be graded on a curve, so students are not competing against each other. Most projects contain extra credits. The midterm is tentatively scheduled on the Thursday of the midterm week.

Projects

We believe that the only way to master the knowledge of operating systems is to build a real operating system kernel. The six projects in this course are designed to do exactly that. At the end of the class, you will have a small, real operating system kernel.  This set of projects were co-developed with colleagues at University of Tromso in Norway.

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.

Late submission policy

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.

Exams

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.

Participation

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.

Collaboration Policy

We believe that students can learn quite a bit from each other. We encourage you to help each other understand the materials in the course and in particular, to learn from each other in doing the operating system projects. In order to encourage such cooperation, we will give you the opportunity to tell us those students who helped you the most in understanding the material. Such information will be turned into extra points for the helpers at the end of the class.

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