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, 1:30–2:45pm; see the Canvas site for the lecture Zoom links.
Section: Biweekly mandatory sections (see schedule).
Class participation is mandatory.
Problem sets. There will be five; the links below will become active as each pset is released.
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 4 late days, with a maximum of 2 late days being applicable to any single assignment.
Students may partner up. However, each student will turn in individual labs. Don’t stress out; see “Policies.”
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 will be an in-class midterm and an in-class final.
Grading schema. A student’s final numerical grade will be calculated using this formula:
Problem set 1: 8%
Problem set 2: 15%
Problem set 3: 15%
Problem set 4: 15%
Problem set 5: 22%
Midterm 1: 8%
Midterm 2: 12%
Final letter grades will be assigned using numerical grade bands that span at least 10 points. For example, if your final numerical grade is between 100 and 90, you are guaranteed to get an A or an A-; if your final numerical grade is between 89.9999 and 80, then you are guaranteed to get some kind of B. Grading bands may be more lenient than 10 points, depending on the overall performance of all students. For example, depending on the overall performance of all students, the grades of A and A- might be mapped to the range [100, 87).
CS 161 labs may be completed in groups, but we expect every student to turn in a separate code repository—even if partners’ code is very similar. Here’s what that means and why we’re doing it.
Partner/group work is an important part of CS 161. Students benefit from talking through their code with partners. There’s less stress and loneliness and easier debugging.
But partner dynamics can hurt too. We want every student to understand the work of every problem set. In partner classes, though, sometimes students shirk work, or trade off (“you do pset 4 and I’ll do pset 5”), which isn’t fair to others and reliably causes problems later. CS 161 has even broken up some relationships! And partner issues force us to put more grading weight on exams.
We seek a happy medium. We want to allow partners but avoid the pathologies of group turnin. So, we ask every student to turn in separate code for each lab. Partners may create this code together, but the code partners turn in must not be wholly identical. A good way to ensure this would be for partners to discuss ideas and code and help each other debug, but type their code individually.
All coursework other than labs must be completed individually.
Collaboration is encouraged on all aspects of the course except exams. You are welcome to communicate with your classmates about strategies for solutions and about specific bugs, and you are welcome to use Internet resources for general information. However:
Do not post your solutions in a public place.
The class will use Ed, not Piazza, 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.
James Mickens: email@example.com
Office hours: Monday/Wednesday 2:45pm–3:15pm; Thursday noon–1pm
Eric Zhang: firstname.lastname@example.org
Office hours: Wednesday 7pm–9pm
Milan Bhandari: email@example.com
Office hours: Sunday 11am–noon; Friday 3pm–5pm
Justin Zhu: firstname.lastname@example.org
Office hours: Sunday noon–2pm
James Conant: email@example.com
Office hours: Monday 7pm–8 pm; Friday 3pm–5pm
Hong-Long (Kit) Nguyen: firstname.lastname@example.org
Office hours: Tuesday 3:30–5:30pm