Skip to content

CS 326 Operating Systems — Fall 2026

4 units · University of San Francisco · Department of Computer Science
Instructor Greg Benson
Teaching Assistant Ankit Mukhopadhyay
Term Fall 2026 — August 25 through December 8
Meetings Tuesday 1h45 (lecture) · Thursday 1h45 (exercise session) · Friday 1h30 (exercise session)
Final exam Tuesday, December 8, in class — the last day of the term

Course Description

The design and implementation of operating systems: processes, threads, scheduling, synchronization, interprocess communication, device drivers, memory management, and file systems.

This offering teaches those topics by building an operating system. Over the semester you implement rv6, a small Unix-like kernel for the RISC-V architecture, written in Rust. By the end it boots on an emulated 64-bit RISC-V machine, manages memory with page tables, schedules multiple processes, handles interrupts and system calls, and runs a shell in user mode — and the programs that shell runs are programs you wrote in the first month of the course.

Nothing is a simulation. Every exercise compiles for real hardware and runs on a real (emulated) machine.

Learning Outcomes

After completing this course you will be able to:

  1. Write systems software in Rust, including the unsafe subset needed to touch hardware, and explain what ownership and borrowing buy a kernel.
  2. Explain the RISC-V privilege model and the calling convention, and read and write the assembly a kernel requires.
  3. Implement physical memory allocation and Sv39 virtual memory, and translate an address by hand.
  4. Implement context switching and a scheduler, and explain how one CPU is multiplexed across many processes.
  5. Implement kernel synchronization primitives and reason about race conditions and deadlock.
  6. Implement the trap path — exceptions, interrupts, and system calls — and trace a system call from user code to kernel and back.
  7. Implement process creation, program loading, and file descriptors, and explain why Unix separates fork from exec.

How This Course Works

Tuesday is lecture. Thursday and Friday are exercise sessions, and the programming happens there, in the room. Your time outside class is for reading.

Day Length Shape
Tuesday 1h45 Lecture on that week's exercises. Ends with a short walk-through of Thursday's and Friday's Prep pages.
Thursday 1h45 Exercise session
Friday 1h30 Exercise session

One lecture is delivered live each week, on Tuesday, and it is about exactly that week's Thursday and Friday exercises. Its page, linked from the Tuesday row of the schedule with its slides, has three parts:

  • Essentials: what Thursday and Friday assume. Read it before Tuesday.
  • For the exam: a short list of examinable topics that no exercise needs.
  • Going deeper: optional material, which is not on the exam.

The lecture cannot cover everything on the page; it covers the Essentials. Two weeks shift because of the calendar: week 9's lecture is given on Tuesday, October 13 (October 20 is fall break), and week 15's two lectures are given on November 24 and December 1.

Every exercise session has a Prep page, linked from its row on the schedule. It says what you will build, which sections of the week's lecture page and which guides to read, and what to check that you understand before you arrive. Read the Prep page before class. It is the bridge between the lecture and the exercise: a student who has read it spends the session writing code, and a student who has not spends it reading.

Exercises are delivered by OSlings, a command-line tool that stages each exercise into your repository, runs its test, and gives hints. An exercise is released at the start of the session that works it and does not exist in your repository before then. Before you leave the room you run oslings submit, whether or not the exercise passes — that submit is your record of the session. See Using OSlings and the Setup page for the first session.

Sessions run on their own Wi-Fi, cs326. You sign in to it once per laptop — join the network, open http://signin.cs326, and sign in with your USF Google account. After that it recognizes your laptop and there is nothing to do at the start of a session. See The Classroom Network.

Exercise work is meant to happen in the room, on that network, and the grade follows where it happened. Work done in the session counts in full; work finished at a make-up session — office hours with the instructor or TA, on the same cs326 network — counts for three quarters; work done anywhere else counts for half. All three stop counting when the exercise's solution is released — normally with the next exercise session, and occasionally sooner, in a solutions-only release before an exam. oslings update names the solutions that have just shipped, so you always know which windows have closed.

Your own work is archived in my-work/, and oslings goto <name> returns you to it.

Assignments and Grading

Component Weight
Module 1 exercises (00r–21r: Rust, commands, bridges to bare metal) 20%
Module 2 exercises (30k–53k: the kernel) 30%
Midterm 1 — Thursday, October 15 15%
Midterm 2 — Thursday, November 19 15%
Final exam — Tuesday, December 8 20%
Extra credit (14c, 41k, 47k, 54k, 55k) up to +3%

Each exercise day is one grade in Canvas, out of 100. A day with three exercises is still one grade.

How an exercise day is scored

Each day is worth 100 points, in two halves.

Being there — 50 points. The class server records how long your registered laptop was connected to cs326 during that day's session. 75 minutes earns the full 50 on Thursdays, 70 minutes on Fridays; less than that earns proportionally less, and more earns no extra. Either section's session on that day counts, and two of your own devices count once.

The exercises — 50 points. Your work is graded by re-running each exercise's real test against what you committed. Grading rebuilds and reboots your code, so a pass in class is a pass at grading time and editing local state cannot manufacture one. A partly-working exercise earns the share of its own tests that pass, counted by the test names the course repository ships — so deleting a failing test lowers your score rather than raising it, and adding a passing one of your own does nothing. The day's exercises are averaged, and the result is multiplied by where the work was done:

Where you did the work Multiplier
In the session, on cs326 × 1
At a make-up session — office hours with the instructor or TA, on cs326 × 0.75
Anywhere else × 0.5

Every distinct version of an exercise you commit is scored this way — the tests it passes times its multiplier — and the best one counts, so a later attempt can raise a score and never lowers one. Two consequences are worth knowing. A finished exercise written at home (every test, × 0.5) can beat a half-finished one written in class, so finishing late is always worth doing. And because versions are compared by their contents, re-committing work you already had buys nothing: bring the unfinished exercise to a make-up session and finish it there. Every version stops counting once that exercise's solution is released.

The multiplier follows the submission that first contained the work, not a later one that merely re-committed it, and being in the room is established by the class server rather than by anything your laptop reports. The oslings submit you run in the room is the evidence — submit before you leave. Extra credit is graded from your repository without a multiplier and without a deadline — where you wrote it does not matter — and is capped at +3%; 55k_pipes, a design exercise with no tests, is read by hand.

Scoring of the network half, and of where the work was done, began on September 10, the day it was announced. The four sessions before it are scored on their exercises alone: everyone has the network half, and every version counts as in-class.

If the class server records nothing at all for a session — it was down, or its clock could not be confirmed — that day is held rather than posted, and the network half is then given to the whole class. A day is recomputed whenever new work arrives, and only ever upward. If a number looks wrong, write in: every grade can be rebuilt from its evidence — the attendance rows behind the minutes, and every version of every exercise with its commit, its time and its tier — and that is the first thing we will do.

Five exercise days are dropped, from anywhere in the semester — five of your 24, not a quota per module. They are applied at the end of the term, once every day has closed, and appear in Canvas as days marked excused. Until then your running total is computed without them, so it can only go up when they land.

The five are chosen to help you the most, which is not always the same as your five lowest: a kernel day carries more weight than a Rust day, so dropping a slightly better kernel day can be worth more than dropping your worst Rust one. Whatever set you would have picked by hand, this one is at least as good. Fewer than five are dropped when a day would not change your grade — a perfect record loses none, and loses nothing by it.

A day is only eligible once its window has closed, so a day you can still finish at a make-up session is never dropped out from under you. Extra credit is separate and is never dropped.

Solutions

The reference solution for an exercise is released into exercises/<name>/solution/ in your repository, and oslings solution <name> prints it. Before that it exists in no repository you can fetch. Solutions ship with a release rather than on a date: normally the next exercise session ships the previous session's solutions, and occasionally one arrives sooner, in a solutions-only release before an exam. Shipping a solution is what closes that exercise's make-up window, and oslings update says which ones just arrived.

Exam and practice-set solutions are posted on the site under Solutions.

Exams

All three exams are given in class. The midterms fall on a Thursday — October 15 and November 19 — in the Thursday session's slot, and there is no Friday session in an exam week. The final is on Tuesday, December 8, the last day of class, in the Tuesday slot. There is no exam during finals week.

Exam Covers
Midterm 1 — Thursday, October 15 Module 1 (00r–21r) and the kernel through paging (30k–33k)
Midterm 2 — Thursday, November 19 Processes (34k) through user mode (48k)
Final — Tuesday, December 8 Cumulative, weighted toward 49k–53k

All three are on paper, closed book, with one permitted reference: the course cheatsheet, which is published on this site and which you may print. No electronic devices.

Exams test understanding rather than recall: tracing registers through a context switch, decoding a page table entry, ordering the steps of a boot sequence, explaining why a race condition occurs. Practice sets in the same style are distributed before each exam.

You must average C or better across the exams to pass the course.

Letter grades

Assigned without rounding or curving:
A 100–93.33 A− <93.33–90 B+ <90–86.67 B <86.67–83.33 B− <83.33–80 C+ <80–76.67
C <76.67–73.33 C− <73.33–70 D+ <70–66.67 D <66.67–63.33 D− <63.33–60 F <60

C is the minimum grade for the CS major.

Course Policies

Academic integrity and the use of AI

This course is unusual, and the reason is worth stating plainly.

rv6 is modeled on xv6 and Octox, which are public and are in the training data of every large language model. An AI assistant can produce a working version of nearly any exercise in this course instantly. That is precisely why the programming happens in class.

So the policy is simple, and the line is drawn at the session:

  • Exercises are done in the room, during the session, on your own keyboard. Exercises are not released before the session that works them, so there is nothing to pre-solve.
  • During a session: no Internet and no AI assistant. The classroom network reaches GitHub, the Rust toolchain, the Rust documentation — the Book, Rust by Example, the standard library, rustlings and the playground — and this site. Very little else, and every AI assistant is blocked by name. No chat window, no editor autocomplete that writes code for you, no phone. What you have in the room is the lecture notes, the guides on the course site, oslings hint, the compiler, and the instructor and TA. The full list is on The Classroom Network.
  • Hints are limited. oslings hint gives two hints per exercise. The third is never released.
  • Outside a session: use AI freely, and often. Ask it to explain a concept, walk you through code you are reading, generate practice problems, or decode a compiler error. That is genuinely useful, it is where a good deal of your preparation should happen, and you are encouraged to do it.
  • Finishing an unfinished exercise happens at a make-up session, on the classroom network, under the same rules: your own work, which you can explain line by line.
  • Do not share your solutions with other students. Explaining a concept to a classmate is good and welcome. Handing over code is not.

The restriction is stated as conduct rather than as a claim about the network, because a phone hotspot defeats any network restriction and nobody is pretending otherwise. Reaching the open Internet or using an AI assistant during a session is an integrity violation whether or not anything stopped you.

You should only submit work you fully understand and can explain. The TA or instructor may ask you to walk through code you submitted; being unable to is treated as an integrity matter.

Data recorded by OSlings

OSlings records, alongside each passing submission, when the session started, how long the exercise took, and how many times you ran the test. This is disclosed here rather than collected silently.

It is not scored, not ranked, and not part of your grade, and it does not appear in any report the course produces. It exists so that if a question ever arises about a submission there is context for a conversation. It is a starting point for a discussion, never proof of anything. What is scored is the connected time described below, and the exercises themselves.

Data recorded by the class server

When you sign in to the cs326 network, the classroom router stores your name, your USF email and your GitHub username — the first two supplied by Google when you sign in, the third from the roster you filled in at the start of term — together with that laptop's network address. While you are connected during a session it records that the laptop was connected, and for how long.

That is the whole list. No browsing history and no page contents are kept: the connections are encrypted, and nothing about what you visit is stored.

Your connected time during an exercise session is half of that day's grade, as described under How an exercise day is scored. That is the only thing here that is scored: not which pages you visited, not how long you sat anywhere else, not the lecture days. The record also exists so that the exercise can be released to the room, and so that if a question arises later about a session there is a record of who was connected.

You may ask to see your own record, and to have it deleted, at any time. Registrations and connection logs are erased at the end of the semester.

Laptops and the classroom network

Sessions run on a restricted network that reaches GitHub, the Rust toolchain and documentation, and this site — so that oslings update, oslings submit and cargo all work and very little else does. You sign in to it once per laptop, and it recognizes you after that.

The Classroom Network covers signing in, the full list of what is reachable, what the class server records about you, and what to do when it does not work. Keeping the room off the open Internet is the rule, not just the router's default; see Academic Integrity and AI for why it is written that way around.

Communication

Course questions go on Zulip so everyone benefits from the answer. Personal matters go by email.

Texts and Resources

No textbook is required. All course material is on this site.

Recommended, and free:

Optional Rust practice, for early finishers and anyone who wants more repetitions than the exercises give:

  • Rustlings — small exercises that run from the command line, in the same spirit as OSlings.
  • 100 Exercises To Learn Rust — a test-driven tour of the language, one concept at a time.

Neither is required or graded.

Run rustup doc for the standard library documentation offline — faster than the network, and it works anywhere. doc.rust-lang.org is reachable from the classroom network too.

University Policies

Students with disabilities. If you have a disability for which accommodations may be required, please contact Student Disability Services (sds@usfca.edu, 415-422-2613) as early in the term as possible. Accommodations are arranged through SDS and are not retroactive.

Academic integrity. The USF Honor Code applies to all work in this course. See the Academic Integrity policy.

Behavioral expectations. All students are expected to behave in accordance with the Student Conduct Code and other University policies.

Counseling and Psychological Services (CAPS). CAPS provides confidential, free counseling to student members of our community. Personal counseling and consultation are available at 415-422-6352.

Confidentiality, mandatory reporting, and sexual assault. As instructors, one of our responsibilities is to help create a safe learning environment. University policy requires that we disclose to the Title IX office any information about sexual misconduct shared with us. Confidential resources are available at CAPS and the Student Health Center.

Learning, Writing, and Speaking Centers. Free tutoring and academic support are available to all students.

USF Food Pantry. Free groceries are available to any student who needs them, no questions asked. Details on myUSF.