This is an in-depth course in operating systems design and implementation, focusing on multicore operating systems kernels. Operating systems are some of the most complex software artifacts that exist. Kernels abstract the features provided by computer hardware, making those features safer and more convenient to use. This means that OS designers have to understand how hardware works (at least at the level of specifications) and how software works. OS programmers also must become comfortable with navigating in, and contributing to, code bases too large to wholly understand. Most of us can pick up this important skill.
Lecture: Monday/Wednesday, 2:15–3:30pm, SEC LL2.224
Section: Biweekly mandatory sections
Class participation is mandatory.
Problem sets. There will be five.
These labs will use the Chickadee framework. For some labs, you will also need to engage with (meaning, read code from) other operating systems, such as Linux. Each student has a total of 6 late days.
Students may work with one another. However, each student will turn in individual code. Don’t stress out; see the section on collaboration, below.
Papers. In some sections we will discuss OS research papers. You’ll need to read the papers before class and engage in paper discussion on Ed.
Exams. There may be an in-class final.
Discussion, collaboration, and the exchange of ideas are essential to doing academic work, and to engineering. You are encouraged to collaborate with your classmates as you work on problem sets; for instance, you may have one or more partners who you frequently collaborate with. You are welcome to discuss general strategies for solutions as well as specific bugs and code structure questions. You may also browse Internet resources for general information (though you may not access prior solutions that may or may not be available on the web).
However, the work you turn in must be your own—the result of your own efforts. You should understand your code well enough that given enough time, you could replicate your solution from scratch, without collaboration and with access to only general reference material. Every student will turn in a separate code base, and we will check that these code bases show evidence of individual work.
You must cite any books, articles, online resources, and so forth that helped you with your work, using appropriate citation practices. We also ask you to list the names of students with whom you have collaborated on labs, and briefly describe how you collaborated. (You do not need to list course staff.)
Limitations and caveats:
In addition to this policy, college students are subject to Harvard College’s academic integrity policies as described in the College Handbook for Students.
Generative AI note: If you use generative AI (e.g., ChatGPT or GitHub Copilot) to help you with the course, you must cite the generative AI as a collaborator and check in full transcripts of your chat sessions with your code (including your prompts). We don’t recommend using generative AI because of problems like hallucination and vagueness—the coding work of this course demands precision—but we’re curious; if you make it work for you, let us know.
Rationale: Students benefit from talking through their code with partners. There’s less stress and loneliness and easier debugging. But we want every student to understand the work of every problem set—that’s what the class is about.
The class will use Ed to host the discussion board. Go the Canvas page for CS 161 to find the sign-up link for the Ed board!
There are no mandatory texts for CS 161, but we can recommend some helpful texts if you like that sort of thing. They can be rented for Kindle.
There are also extensive online resources on kernel design, architecture, and operating systems development.
And also many online resources (of varying quality and age) on C++. Here are some good ones.
Office hours: SEC 4.412, Tuesday 2–4pm, or whenever I’m in the office and available