danos/docs/vision.md

Vision: a microkernel, built to learn

danos exists first and foremost as a learning-by-doing project: the point is to build a real operating system, bump into the hard constraints for real, and research them from a position of having actually hit them. The docs in this folder are part of that — they're where a constraint gets understood once it's been met.

That framing sets the priorities. danos is not chasing a spec or a product; it's chasing understanding, with a concrete, motivating win condition to aim at.

The win condition

danos is a "win" when it:

• boots and runs on real hardware — the author's PC (x86-64) and both Raspberry Pis: the Zero 2 W and the Pi 5 (both aarch64, one backend — see arm.md),
• has a graphical user interface, ideally — building on the framebuffer it already draws to.

Everything below serves that, or serves the curiosity that the project runs on.

Why a microkernel: resilience

The kernel stays minimal — only what genuinely must run privileged:

• scheduling,
• inter-process communication (IPC),
• memory management (address spaces, page tables),
• low-level interrupt dispatch.

Everything else — device drivers, filesystems, the GUI, the network stack — runs as an isolated user-space server, each in its own address space with only the privileges it needs.

The reason for this shape is resilience: the ability to re-initialise parts of the OS while it runs. A driver bug can't corrupt the kernel or another driver; a crashed or wedged component is contained, killed, and restarted — "if I break something, I can just fix it," without rebooting. Keeping the kernel tiny is part of that strategy: the one thing that can't be restarted is the trusted base, so the less code in it, the less that can take the whole system down. This is the project's real motivation, and it has its own design note: resilience.md.

The cost is that IPC becomes the backbone: what used to be a function call inside a monolithic kernel is now a message between address spaces. In a microkernel, IPC performance essentially is system performance (the lesson of L4), so it's a first-class concern. Hardware interrupts become IPC too: the kernel turns an IRQ into a message to the driver that owns the device.

On real-time: an option, not a commitment

danos was originally framed as a hard real-time OS. That's now held as one interesting constraint to explore, not a requirement — because real-time is a pervasive invariant (every operation must be provably time-bounded, everywhere) that would slow every milestone, whereas resilience is a set of structural features that's lighter to build and is what the project actually wants. The trade-off is written up in smp.md.

What danos keeps from the real-time direction, because it's cheap and useful anyway:

• Fixed-priority preemptive scheduling — the highest-priority ready task runs, and preemption lets a runaway component be interrupted and killed (which serves resilience). Already built (scheduling.md).
• A calibrated, deterministic clock — already built (device-interrupts.md).

What danos does not owe anyone unless it deliberately chooses real-time later: timing guarantees, priority inheritance, bounded allocators, tickless timers, MCS scheduling contexts. Concretely, the current heap is a first-fit free list with unbounded allocation time — fine here, and only a problem if a hard-real-time path is ever added. Note that QNX is both a real-time and a restartable microkernel, so choosing resilience now doesn't close the real-time door — it just doesn't pay the tax yet.

The roadmap — tracks, not a strict line

Because the driver is curiosity plus the win condition, the roadmap is a set of tracks with dependencies, not a rigid sequence. Pick by interest; mind the prerequisites.

Done: UEFI boot, framebuffer + serial, physical frames (with boot-services memory reclaimed), paging with W^X, exceptions and interrupts, a calibrated timer + ns clock, a heap, a fixed-priority preemptive scheduler with blocking, in-kernel IPC channels, SMP (all cores scheduling, with affinity), a higher-half kernel with a physmap, and user space: per-process address spaces, syscall/sysret with the swapgs discipline, a user-ELF loader, and /system/services/init — a real user ELF built from system/services/init/, running at CPL 3 as PID 1 on its own page tables — plus a test harness.

• Isolation track — user mode + address-space isolation. Done: a higher-half kernel with a physmap (the low half is user space), per-process address spaces with CR3 switched on context switch, the swapgs discipline, syscall/sysret, a user-ELF loader, and /system/services/init running as a real preemptive ring-3 process (PID 1). Remaining polish: an address-space/stack reaper for exited tasks, SMAP + fault-recovering copy-in/out, the real IPC syscalls (IPC_Call/IPC_ReplyWait — they arrive with the second user server), and TLB shootdown once a process has more than one thread.
• Resilience track — fault → kill → notify, a supervisor/reincarnation server, resource cleanup on death, then a restartable driver as proof. Needs isolation. See resilience.md.
• ARM track — the aarch64 port so danos runs on the Zero 2 W and Pi 5. Largely independent of the others (it's the arch layer); directly serves the win condition. Likely via aarch64-UEFI first (QEMU virt + AAVMF), then real boards. See arm.md, and discovery.md for the device tree it needs.
• GUI track — a framebuffer-based windowing/compositor, and the input + display drivers under it. Builds on the neutral framebuffer (so it's arch-independent), and on the driver model from the isolation/resilience tracks. The visible payoff.

The natural spine is isolation → (resilience + drivers) → GUI, with the ARM track pursued alongside whenever the itch to see it boot on a Pi wins out.

How to use this page

Read it before adding anything structural. When a design decision comes up, the question is: does it serve the win condition (runs on the three machines, with a GUI), or the learning (a constraint worth meeting)? If it serves neither — e.g. paying the full real-time tax with no payoff in sight — it can wait.