OSlings

Operating systems get taught twice. Once as a set of concepts in lecture, and once as a codebase you are told to read. The gap between those two is where most students lose the thread, because reading a working kernel tells you what someone decided, never why the alternatives failed.

It is being adopted for the operating systems course I am a teaching assistant for this coming semester, so a class will work through it: reading each lesson, solving one exercise at a time, and building the kernel in sequence with the test harness running against their code as they go.

OSlings closes that gap by handing you a kernel with holes in it. You work through booting, paging, processes, scheduling, locks, a filesystem, traps and interrupts, then a shell running in user mode. Every exercise follows the same rhythm: read the concept, read and annotate the code around the hole, then fill the hole until the test passes. Rust gets taught in the same motion, at the point where an OS concept makes you need it, so there is no separate Rust course to sit through first.

A green test means the kernel booted

Every exercise carries two test modes. The build mode passes when the kernel compiles for the bare-metal target. The QEMU mode boots the kernel and watches the serial console for OSLINGS:PASS.

That second one matters more than it looks. A unit test on kernel code can pass while the kernel itself refuses to boot, and a student who sees green on broken code learns the wrong lesson twice: once about the concept, once about what testing is worth. Reading the serial output of a real boot removes the gap between "my code compiles" and "my code runs."

The cumulative curriculum is a build problem

Each exercise starts from a kernel that already contains everything you finished before, plus fresh IMPLEMENT markers for the current step. That sounds like a content decision. It is mostly a tooling one.

It means the course cannot be a folder of independent exercises. Every step is a snapshot of one continuously growing kernel, and the starter code for step twelve has to be generated from the solved state of step eleven. Get that wrong and a student rebuilds the same paging code four times, which is exactly the tedium the format exists to remove.

Difficulty is a gate on hints, not on content

Three settings: guided, standard, challenge. They do not change what you build. They change how much scaffolding sits inside the skeleton and how early hints unlock.

Same reasoning as the cumulative build. The thing worth protecting is the sequence of ideas. What varies between a student on their first systems course and one who has written C for years is how much of the surrounding structure they need spelled out, not which concepts they should meet.

Instructor tooling

I have been a teaching assistant for the operating systems course, so the grading side got built alongside the learning side: snapshot-based grading, batch grading across a roster, a student template generator, and an environment checker that confirms rustup, QEMU and the bare-metal target are all present before anyone files a bug about it.

The environment checker earns its place first. On a course where the toolchain is nightly Rust plus riscv64gc-unknown-none-elf plus QEMU 7 or later, most early support requests are setup problems wearing the costume of a code problem.

Why there is no source link

The repository holds the solved kernel for every exercise. It is shared with the instructor and stays private while the course runs, for the obvious reason.