What a Rust Linux 0.11 Rewrite Actually Proves

Linux 0.11 is small enough to hold in your head and complete enough to be a real Unix: processes, demand-paged virtual memory, a filesystem, a console, and a syscall surface that can run a shell. That is exactly why linux-0.11-rs is interesting. It rebuilds that 1991 kernel from scratch in modern Rust, boots on emulated i386 in QEMU, and runs a self-hosted userland with a std-shaped library and a real shell.

The thesis is simple. This is a sharp educational case study in how far idiomatic Rust can go for classic kernel work at a known scale. It is not evidence that "the kernel" is about to become a Rust project, and treating it that way misses the actual value.

Why 0.11 is the right target

Linux 0.11 is a teaching artifact that still behaves like an OS. You get CoW fork, demand paging, Minix v1, ATA, VGA plus PS/2, an 8250 serial console, a TTY layer, signals, and a complete syscall table relative to that era. Floppy support is intentionally left out. Everything else is close enough to the original semantics that you can compare designs side by side with the C sources (the project used yuan-xy/Linux-0.11 as a reference, and also drew on ideas from rCore).

That constraint is the point. A rewrite of a modern kernel would drown in drivers, lock discipline, and ABI politics. 0.11 forces the interesting questions: how do you express process tables, page tables, and a syscall boundary in Rust without turning every path into unsafe soup? How much of the original structure do you keep when the language wants ownership, modules, and types that C never had?

The answer here is deliberate conservatism on what the system does, and deliberate modernity on how it is written. Stronger types, clearer module boundaries, idiomatic abstractions. Same Unix-shaped machine.

The interesting part is not the kernel alone

Plenty of hobby kernels print "hello" over a UART and stop. This one ships a user-space story that is unusually complete for a teaching OS.

user_lib mirrors the public shape of std::{fs, io, path, env, process, time}. User programs read like ordinary Rust instead of raw syscall wrappers. On top of that sits a hand-written POSIX-subset shell with pipelines, control flow, functions, globbing, command and arithmetic substitution, plus an interactive line editor with Tab completion and history. The disk image build packs on the order of seventy binaries into /bin (the project demo shows 69; the tree also describes dozens of coreutils plus sh). Companion crates mbrkit and miniximg handle MBR and Minix v1 images and are published as standalone tools.

That stack matters more than another bare-metal println!. It means you can exercise the kernel the way a developer actually would: fork, exec, pipes, files, signals, interactive I/O. End-to-end tests boot QEMU and drive the serial console from short .ktest scripts. This is closer to "can Rust express a small Unix cleanly?" than "can Rust touch MMIO?"

What this means if you work on systems code

If you already write kernel modules, firmware, or low-level services, treat this as a lab, not a product path.

Who it helps. People learning OS internals who already prefer Rust, or Rust developers who have never walked a fork path or a page fault. Also useful if you have done rCore-style tutorials and want something closer to historical Linux layout (i386, Minix v1, classic syscall table) instead of a clean-slate teaching ISA story.

How you actually run it. The intended loop is boring on purpose: build the disk image, boot the kernel, land in a shell.

tools/build-disk.sh
cd kernel && make run          # VGA
# or
cd kernel && make run-console  # serial, -nographic

Outside the included devcontainer you need a pinned Rust nightly (rust-toolchain.toml), qemu-system-i386, the x86_64-linux-gnu-* cross binutils, and the local image tools via tools/install-tools.sh. Tests:

tools/run-tests.sh
tools/run-tests.sh --suite=shell

What it replaces in a curriculum. It competes with reading the original 0.11 C tree, with rCore and similar Rust teaching kernels, and with writing your own freestanding no_std toy. It does not compete with Rust-for-Linux (in-tree modules against a living C kernel), with Redox, or with shipping a real OS. Different problem.

Trade-offs you should not paper over.

• Target is emulated i386 only. No modern multiarch, no SMP story worth mentioning, no path to hardware you care about at work.
• Filesystem is Minix v1. Fine for pedagogy. Useless as a model for ext4, XFS, or anything networked.
• Feature-complete relative to 0.11 is a low bar by design. Polish and tooling are the ongoing work, not "catch mainline."
• Idiomatic Rust still means unsafe at the hardware boundary. The win is shrinking and documenting those islands, not eliminating them. Anyone selling "safe kernels" without that caveat is selling posters.
• A std-shaped user library is a teaching affordance. It is not a claim that a real libc or std port falls out for free on bare metal.

If it pans out as a long-term project, the durable artifact is probably the walkthrough (an mdbook tutorial is already sketched) plus the image tooling. The kernel itself is a fixed historical target; the process of re-expressing it is the product.

What it does not prove

Context from the wider Rust-on-systems world makes the ceiling obvious. QEMU itself is growing Rust for new device models (safe SysBusDevice work, bindings crates, Meson plus cargo workflow), which is incremental engineering inside a large C codebase. Linux's own Rust support is about modules and drivers beside C, not a rewrite. Bare-metal AArch64 "hello UART" series and out-of-tree module experiments answer different questions.

linux-0.11-rs sits in the educational rewrite lane: full control, frozen semantics, one machine model, one FS, one boot path. That is the best place to practice ownership-aware kernel design. It is a terrible place to infer timelines for production kernels, driver ecosystems, or "C is done."

So call it correctly. Stronger types and clearer modules around a known Unix kernel are real. A bootable shell with pipes and demand paging in idiomatic Rust is real. A signal that 1991 Linux was the hard part of 2026 Linux is not.

Use it to learn how process and memory subsystems want to be structured when the language fights aliasing and lifetime bugs. Do not use it as a proxy war about mainline. The code boots. The lesson is scoped. That is enough to make it worth a weekend and a careful read of the fork and fault paths, and not enough to reorganize anyone's roadmap.