Learning roadmap
Understand how m3OS grows from boot code into a usable operating system.
Study 73 roadmap phases and 9 subsystem pages that explain why each milestone exists, how the implementation works in m3OS, and where a production OS would make different tradeoffs.
Roadmap phases
73 Generated from the m3OS phase corpus now published in this site.Completed phases
64 Already implemented in m3OS and documented with design decisions and tradeoffs.Core components
9 Subsystem pages that trace where schedulers, IPC, VFS, and other pieces appear.Planned phases
8 Future milestones you can study before the implementation lands.How to use this site
- Start with the foundations — Follow the earliest phases in order to see boot, memory, interrupts, and tasking become the base layer for everything else.
- Follow subsystem threads — Use component pages to trace how one subsystem shows up across multiple phases instead of reading the roadmap as isolated milestones.
- Compare against real OS design — Each phase page calls out where m3OS intentionally stays simple and what a production kernel usually adds in exchange for scale, performance, or compatibility.
What each phase page explains
- The design decisions and learning goal behind the phase, not just the task list.
- Important files and code spotlight links back to the upstream m3OS repository.
- How the phase builds on, extends, or replaces earlier work in the roadmap.
- What a real operating system would do differently once the teaching version is understood.
Start here
Foundational phases worth reading first
Phase 01
CompleteBoot Foundation
Boot the kernel through UEFI, print useful output over serial, and halt cleanly. This is the first end-to-end proof that the workspace, toolchain, boot path, and panic path all work together.
Phase 02
CompleteMemory Basics
Move from a static early kernel into a kernel that can allocate memory safely and reason about physical and virtual address space.
Phase 03
CompleteInterrupts
Handle exceptions and hardware interrupts reliably enough to support timing, keyboard input, and basic fault diagnosis.
Phase 04
CompleteTasking
Introduce multiple concurrent execution contexts in the kernel and make timer-driven preemption visible and understandable.
Phase 06
CompleteIPC Core
Turn the kernel into a real microkernel by making userspace services communicate through explicit message passing and capabilities.
Phase 10
CompleteSecure Boot
Sign the kernel's EFI binary so it can boot on real hardware with UEFI Secure Boot enabled, without needing to disable the firmware security check.
Look ahead
Planned work that expands the system
Phase 54
In progressPost Serverization Kernel Hygiene
Close the `FdEntry` CLOEXEC / NONBLOCK plumbing gap and relocate the four `arch::x86_64::syscall::*_pub` wrappers into their owning subsystems so later phases do not inherit a silent security bug or a process-module arch dependency.
Phase 55
PlannedHardware Substrate
m3OS supports a small, deliberate reference-hardware matrix with a documented driver strategy, a reusable hardware-access layer, and at least one serious real-hardware storage and networking path. The project stops talking about hardware support as a vague future aspiration and starts treating it as a bounded support promise.
Phase 56
PlannedDisplay And Input Architecture
m3OS gains a real display and input model: one userspace-owned display service controls presentation, keyboard and mouse events are routed through an explicit focus-aware protocol, and multiple graphical clients can coexist without raw framebuffer conflicts.
Phase 57
PlannedAudio And Local Session
m3OS supports a minimal local interactive session that feels like a system rather than a demo: there is a defined graphical session entry path, a basic terminal or launcher workflow, and audible PCM output on the supported platform.
Phase 58
PlannedRelease 1 0 Gate
m3OS defines and validates what "1.0" actually means. The phase produces an explicit support matrix, release gates, non-goals, and documentation commitments for either a headless/reference 1.0 or a broader local-system milestone if the optional graphical branch is ready.
Phase 59
PlannedCross Compiled Toolchains
m3OS can host larger post-1.0 development tools built on the host and bundled into the disk image. git, Python, and Clang become routine parts of the developer environment instead of future one-off experiments.
Subsystem map
Jump into the components that span multiple phases
Introduced in
Userspace EntryProcess Model
The process model defines what a userspace program is in m3OS and how execution moves into and between processes.
Introduced in
Boot FoundationBoot Path
The boot path moves the system from firmware and build tooling into a running kernel with visible early diagnostics.
Introduced in
Storage And VFSVirtual File System
The virtual filesystem makes multiple storage backends look like one coherent tree to the rest of the OS.
Introduced in
Memory BasicsMemory Manager
The memory manager owns frame allocation, virtual mappings, and the policies that let later phases isolate work safely.
Introduced in
Userspace EntryTerminal Stack
The terminal stack turns raw console I/O into an interactive environment people can actually use.
Introduced in
TaskingScheduler
The scheduler decides which runnable work executes next and turns a single control flow into a real operating system.