CS370: Operating Systems

[Schedule]

[Assignments]

Assignments

All assignments are due at 8:00 PM on the due date. There is a late penalty of 10% per-day for up to a maximum of 2 days. All assignments will be posted at least 2 weeks prior to its due date. We will have a mix of both written and programming assignments. All assignments will be posted on this page. No assignments will be accepted more than 4 days past the due date.

All assignments should be submitted using Canvas.

Required Use of Claude Code
You are required to use Claude Code for all assignments and to log that usage, but the goal is for you to leave the assignment understanding every line you submit, and not just produce working code by any means available.

	Release	Due Date
HW-0 [Optional]	7/21	None
HW1	8/25	9/16
HW2	9/16	10/14
HW3	10/14	11/11



Term Project	8/3	TP-D1: 9/23 Covers milestones 0 & 1 TP-D2: 10/28 Covers milestones 2 & 3 TP-D3: 12/9 Covers the remainder of the milestones.

Programming Exercise: Building a Memory-Safe Red-Black Tree in C Under Kernel-Style Constraints

A red-black tree is a data structure that keeps itself balanced, so that searches, insertions, and deletions all stay fast. You will build one. That is where the assignment begins, and it is the easy part.

Then the ground shifts. Again and again, the assignment changes the rules about where your tree's memory lives and how it may be reclaimed: allocations that fail halfway, memory drawn from a pool you wrote yourself, a stack too small to recurse on, two trees quietly sharing the same bytes. Each change mirrors a problem real operating systems face every day. Your tree must survive all of them while behaving, on the outside, exactly as before.

Additional details are available here.

Here's the companion walkthrough for the assignment.

Release date: July 21st

Assignment 1:Red-Black Tree in C
Pointers, ownership, memory-safety verification, and disciplined AI-assisted development

In this assignment, you will build a red-black tree in C. The tree must support insertion, lookup, traversal, deletion, validation, and clean teardown while preserving the red-black invariants and passing strict memory-safety checks with AddressSanitizer and valgrind. You will work through the implementation in milestones rather than trying to land everything at once. Claude Code is required, but the goal is not to have it “do the assignment.” You are expected to use it iteratively: ask questions, make small changes, test, inspect failures, and keep control of the design. Your Claude Code transcripts form part of the assessment, as does a short personalized walkthrough based on your own code. The tree you build here will return later, under much less forgiving kernel-style constraints.

Additional details are available here.

Here's the companion walkthrough for the assignment.

Release date: August 25
Due date: 9/16

Assignment 2:

Release date: 9/16
Due Date: 10/14

Assignment 3: Writing a shell from scratch with support for arbitrary pipelined operators with support for shared memory

Release date: 10/14
Date date: 11/11

Term Project:A Device Someone Needs: Two Sensors, a Raspberry Pi, and Software You
Can Defend.

Forget the usual assignment format. This one hands you a person, not a spec. You'll find someone with a real problem, something a phone app can't quite solve, and build a device that actually solves it: a Raspberry Pi, at least two sensors, and software you wrote from scratch to run the show.

Here's the twist. Claude Code is required while you're building, but it's banned from what you ship. Every decision your device makes on its own, every detection, every diagnosis, has to be code you understand well enough to defend, out loud, by yourself. The agent can help you build the machine. It can't be the machine.

Why does this matter for an OS course? Because the interesting problems only show up when nobody's watching. Your device has to survive 3 a.m., alone, unattended, on the one day something actually happens. That's where processes, schedulers, interrupts, and IPC stop being lecture material and start being the reason your project works or doesn't.

You'll work in teams of two. There are 5 seed ideas to get you thinking (wellness monitoring, environmental coaching, security, predictive maintenance, and so on) but the best projects tend to wander off the list entirely! What doesn't budge is the evidence. Your system needs to run 48 hours unattended and prove it with logs. Your latency and reliability numbers need to be measurements, not vibes.

And here's the part people relax about too early: nobody expects perfection. Your budget is small, your sensors are cheap, things will break. What matters is what you did with what you had, and whether you can explain it honestly. The project ends with a live demo and an individual defense, so know your code. All of it. Even the parts that your teammate wrote.

Additional details are available here.

Due Dates:
TP-D1: 9/23
Covers milestones 0 & 1

TP-D2: 10/28
Covers milestones 2 & 3

TP-D3: 12/9
Covers the remainder of the milestones.

Extra Credit: Still thinking about this ...