Carnegie Mellon
SCS logo
Computer Science Department

15-410 Expectations

Course objectives

15-410, Operating System Design & Implementation, is a programming-intensive OS class. The core experience is writing a small Unix-inspired OS kernel, in C with some x86 assembly language, which runs on a PC hardware simulator called Simics (and on actual PC hardware if you wish). Work is done in two-person teams, and "team programming" skills (source control, modularity, documentation) are emphasized. Core concepts include the process model, virtual memory, threads, synchronization, and deadlock. The course includes one medium-sized non-textbook reading assignment with a writing component. If you have already completed an implementation-intensive OS class (one based on, e.g., NACHOS), ECE's Embedded Systems class might be a better opportunity for growth. Finally, past experience suggests that 15-410 is a challenging class. Students who successfully complete it will learn a lot, but it will not be easy.

About This Document

This document sets forth our high-level expectations for the class. You must also read the companion document on Policies & Mechanisms.


The textbook is Operating System Concepts, by Silberschatz, Galvin, and Gagne. It is available in CMU's bookstore. Various flavors of the sixth edition should be ok, and students have used the fifth edition without difficulty in the past. We will not cover all of the text, and some topics (such as synchronization) will be taught in a different manner.

You may also find useful the 15-213 textbook, Computer Systems: A Programmer's Perspective; the K&R C book; and perhaps C Traps and Pitfalls.


According to the SCS Undergraduate Courses page, the official prerequisite for this class is 15-213 (Introduction to Computer Systems). It will be very difficult for you to successfully complete the course without the relevant background experience.

Less formally, you should know what a byte is, what a register is, the meaning of "1<<2", the difference between a process and a thread, roughly what goes in a stack frame, what virtual memory is, what a cache is, etc. You should be proficient in C programming on UNIX systems, including the use of make and a source-level debugger such as gdb or dbx. The class will require writing small amounts of x86 assembly language, and debugging your OS will require you to be able to map back and forth between C and assembly language, so it is very important that you have had some experience in this area before.

ECE students who have done well in 18-347 (Introduction to Computer Architecture) and who have acquired proficiency in C programming on Unix may be in good shape. Homework or exam questions may call for simple proofs or inductive reasoning. If you are unsure about your preparation, please consult your advisor and, if necessary, the course instructor.

If you are not from CMU you will probably wish to consult the web sites of those classes for further information.

Course Activity

Students are encouraged to attend lectures, as some material will not be covered fully by the textbook. Likewise, reading the relevant sections of the text is wise, and some people will find a second or third reading of some sections useful. In other words, most students who do well in the class will attend lectures regularly and read the textbook thoroughly.

We will grade homeworks, a "book report" assignment, several programming assignments, a mid-term exam, and a final exam.

In slightly more detail:

Homework assignments

Homework assignments are individual assignments designed to reinforce class material through design, analysis, restatement, or simple practice. Although each student should do his/her own homework, students are certainly encouraged to discuss the course material related to the homework to develop a better understanding.

Team Projects

Projects (other than the first two) are designed for two person teams. When choosing a partner, try to ensure that the relationship will last for the remainder of the semester. We will allow changes if the situation merits it and if alternative partners are available. While some people end up working by themselves, we actively discourage this and generally don't view it as a reason for relaxed deadlines or grading.

Both partners should work cooperatively on the design, implementation, and testing of their solutions.

The programming assignments, especially the kernel assignment, are not easy. It is far from unusual for a single one-line bug to take two days to track down. You should plan to finish each project 10%-20% early.


The exams may cover any material covered in the course. This includes the material from the lectures, from the assigned sections of the textbook, from the additional reading assignments handed out, from the programming projects, or from the homework.

Team Programming

Most of the programming effort will be in a team-programming context, to give you experience with the design strategies, coding standards, documentation practices, source control techniques, and people skills you are likely to need in both industry and academia. Here we differentiate between team programming and software engineering in that we will not cover requirements analysis, release staging, defect management, and other life-cycle issues.

You may experiment with various development styles. Some students explore "Extreme Programming", and others have had good experiences with Pair Programming (Williams & Kessler).

You should probably discuss your committment to the class with potential partners. For example, if it is spring semester and you are planning to graduate, a first-year drama student auditing the class might not make the best partner for you.


Our overall expectation on grades is:

All parts of problem addressed
Solution is complete, stable, robust; no major design flaws, etc.
Excellent: design is clean, documentation is complete, error handling and logging are good. Probably one or more "good-quality" algorithms are used (as appropriate); it should be credible that somebody might want to re-use some of your code; often you will have done a little bit more than what we asked in a couple of areas.

Academic Conduct

In general, collaboration is good when it furthers genuine learning and bad when it doesn't. Meanwhile, plagiarism (using the work of others without giving them appropriate credit) is definitely bad. This principle can often help you decide between good collaboration and bad collaboration: if you would feel bad about accurately giving credit for part of your program, then it probably shouldn't have been created however it was. Another good rule is that if you're not sure whether something is ok, you should ask the course staff.

Also, in general, we expect you to behave honestly and according to high standards of academic conduct.

Reminder About This Document

This document sets forth our high-level expectations for the class. You must also read the companion document on Policies & Mechanisms.


Ideas (and even some text) were stolen from Greg Kesden's 15-412 syllabus and Randy Bryant & Hui Zhang's 15-441 syllabus.

[Last modified Wednesday September 01, 2004]