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. This is an important skill that most people can pick up.
Lecture: Tuesday/Thursday, 1–2:30pm, Pierce 301 Section: TBD
This year, we are building a new version of the course. We will use Chickadee, a new operating system based on CS 61 WeensyOS. Chickadee aims to be smaller than OS/161, and to take advantage of newer hardware, language, and OS design features.
Chickadee is new. The course will have rough edges! We are unlikely to have extensive autograding infrastructure. But those who join us will have fun and shape CS 161’s future.
Class participation is mandatory.
Labs. 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.
As in prior years, students may partner up. Unlike prior years, each student will turn in individual labs. Don’t stress out; see “Policies.”
Papers. In some lectures we will discuss OS research papers. You’ll need to read the papers before class and engage in paper discussion on Piazza.
Exams. There will most likely be a midterm and a take-home final.
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, and even larger teams (with instructor permission), 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, and may share code, but the code partners turn in must not be wholly identical. A good way to ensure this would be for partners to pick at least one part of each lab and type in their solutions for that part individually. Another good way would be for partners to discuss ideas and code and help each other debug, but type everything themselves.
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.
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.
Lecturer: Eddie Kohler, email@example.com, MD 327
TF: Thomas Lively, firstname.lastname@example.org
TF: Abby Lyons, email@example.com
TF: Garrett Tanzer, firstname.lastname@example.org