Carnegie Mellon
SCS logo
Computer Science Department
home
syllabus
staff
schedule
lecture
projects
homeworks
 
  

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.

Textbook

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.

Prerequisites

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.

Almost all students should complete not only 15/18-213/513 but also a 15-4xx/6xx Systems elective before taking this class. SIO lists 213 as the sole prerequisite for this class, but what's in SIO is what's mandatory, not what's wise. Some students who have had 213 but not one of the other Systems electives can do fine, but that is the rare case, not the common case. If 213 is your sole preparation to date involving programming and Systems concepts, the prudent thing would be taking one of the other 15-4xx/6xx Systems electives (411/611, 418/618, 440/640, 441/641, 445/645) first. Exceptional cases may exist (e.g., a summer internship writing UEFI firmware), but should be discussed with one's advisor before enrolling.

Course Activity

While we do not take attendance in class, we expect students to attend lectures—"synchronously", in the modern locution. 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. Knitting and crotcheting in class are fine (needlepoint may be, with instructor approval).

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 ("synchronously") 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.

Exams

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.

Grades

Our overall expectation on grades is:

C
All parts of problem addressed
B
Solution is complete, stable, robust; no major design flaws, etc.
A
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.

Respect for Diversity

It is the intent of the course staff that students from all diverse backgrounds and perspectives be well served by this course, that students' learning needs be addressed both in and out of class, and that the diversity that students bring to this class be viewed as a resource, strength and benefit. It is our intent to present materials and activities that are respectful of diversity, including: age, background, beliefs, caste, culture, disability, ethnicity, gender, gender identity, gender expression, national origin, religious affiliation, sexual orientation, socioeconomic status, and other visible and nonvisible categories. We want all students in the class to succeed. Your suggestions are encouraged and appreciated. Please let us know ways to improve the effectiveness of the course for you personally or for other students or student groups. In addition, if any of our class meetings conflict with your religious events, please let us know so that we can discuss appropriate arrangements. (The preceding wording is based on a statement from the University of Iowa College of Education and a statement written by Chad Topaz of Mathematics at Williams College.)

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.

Acknowledgements

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 Tuesday August 29, 2023]