Carnegie Mellon
SCS logo
Computer Science Department

15-410 Expectations

About This Document

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

Learning Objectives

Operating System Design and Implementation is a rigorous hands-on introduction to the principles and practice of operating systems. 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 (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.

Students who successfully complete the course will:

  • synthesize externally-provided specifications and manufacturer-provided technical documentation into a considered design,
  • compare and contrast the properties of memory regions according to the Unix process model,
  • compare and contrast the properties and roles of x86-32 registers,
  • explain the interactions of input/output operations and per-thread scheduling states,
  • implement address spaces in terms of both high-level data structures and hardware registers and tables, including TLB management,
  • explain why and how multiple threads are used in a single address space,
  • analyze and write lock-based multi-threaded code and lock objects, including detecting and documenting race conditions and deadlock,
  • explain the relationship between interrupts and other forms of concurrency,
  • use multiple tools and approaches to debug concurrency-related code failures,
  • write robust code that responds appropriately to resource exhaustion,
  • write clear, appropriately documented code,
  • define and illustrate key computer security concepts such as protection domains, capabilities, access control lists, and least-privilege execution,
  • define, illustrate, and apply, in a basic fashion, key computer security technologies such as secure hashes, symmetric cipers, and asymmetric ciphers,
  • describe and illustrate key elements of higher-level operating systems features such as file systems, interprocess communication, real-time scheduling, disk arrays, and log-based storage,
  • study an OS-related topic via a medium-sized non-textbook technical reading assignment and report in writing on what was learned.

Students are expected to use the course assignments as a vehicle to practice and develop skills for working in "team programming" situations and/or large code bases, e.g.:

  • revision control,
  • preparing detailed, evidence-based requests for assistance and advice,
  • maintaining a "bug diary" to support debugging based on explicit hypotheses and multi-technique measurements,
  • coordinating development and testing with a co-worker, including via pre-scheduled, recurring meetings with pre-set agenda items and explicit inter-meeting per-person responsibilities,
  • planning a development path before development (and revising it during development)

Performance of these higher-level skills will not be explicitly graded, but there is a strong correlation between the students who invest in them and students who achieve better-than-passing course grades.

Target Audience

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


The traditional textbook is Operating System Concepts, by Silberschatz, Galvin, and Gagne. We provide a table mapping reading assignments to the 6th through 10th editions of the book. The newer editions are more up-to-date on some topics, but they are also more expensive. What you get out of the textbook depends more on how much time you spend with it than on which edition you have, though you probably want to avoid some of the stranger sub-editions, e.g., "Essentials" or "with Java". We will not cover all of the text, and some topics (such as synchronization) will be taught using additional material. Rumor has it that the OSC text is available (purchase or rental) as an e-book from at least one major e-book vendor. As we have no experience with this format, if you try it, please let us know whether you like it.

The experimental textbook is Operating Systems: Principles and Practice, Second Edition, 2014, by Anderson and Dahlin:

You may also find useful the 15-213 textbook, Computer Systems: A Programmer's Perspective, Third Edition; the K&R C book; and perhaps C Traps and Pitfalls. An excellent source of suggestions for programming style and structure is Brian Kernigan and Rob Pike's The Practice of Programming, especially the first few chapters.


According to the SCS Undergraduate Courses page, the official prerequisite for this class is 15-213 (Introduction to Computer Systems). If you have not completed 15-213 with a grade of C or above, you must contact the course staff and complete a skill assessment exercise to remain registered in the class. This requirement specifically includes all graduate students, exchange students, non-degree students, and any other special students. This also includes all students who have taken Operating System classes other than 15-410.

Furthermore, please be aware that this course relies on skills acquired in 15-213. This means you'll be in trouble if much of what was covered there has been forgotten, or if finishing it was a significant struggle. You should recall 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, what locality is and why it matters, how file descriptors work, what fork() does (and does not do), 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 are have retained these skills. If necessary, you should re-read all of your 213 code before starting work on the projects for this class.

Course Activity

While we do not take attendance in class, we expect students to attend lectures. If you miss a lecture, we expect you to arrange for a fellow student who was in class to teach you what you missed by going over the lecture slides with you. When possible, it is probably wise for you to obtain the agreement of a particular fellow student before the class you miss. Our model for the lecture slides is that they support the lecture and can also support a student-led recapitulation, but that they do not replace the lecture.

While some material will not be covered fully by the textbook, the text will expand on some material covered only partially in class. Thus, reading the relevant sections of the text is wise, and some people will find a second or third reading of some sections useful.

In general, 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.

Please note that the default outcome for any academic integrity violation is a failing course grade for the semester; the violation will be reported to your home academic unit and the Office of Community Standards and Integrity. Please don't get involved in this--it costs everybody enormous amounts of time during which nothing can be learned about operating systems. If you are having trouble with one assignment but struggle within the rules, you might end up with a failing grade for that assignment, but you may well be able to pass the course, or drop and take it again later. Willfully violating the policies of the course, on the other hand, threatens your opportunity to ever pass the course. Also note that repeated or sufficiently egregious violations of academic integrity standards may result in penalties more severe than failing this class, such as permanent separation from the university.

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, Randy Bryant & Hui Zhang's 15-441 syllabus, and Bob Harper's 15-312 syllabus.

[Last modified Monday January 14, 2019]