Rebuilding it properly.
The rewrite is a clean-room kernel in GNU C23 that shares no code with the prototype. It aims for everything v0.4.1.0 did, rebuilt one subsystem at a time on explicit, tested contracts, and it does not move on until each one passes on real hardware.
The rewrite booting under QEMU. For now, instead of a desktop, each build finishes on a set of live diagnostic screens that prove what the kernel has actually brought up on this machine: driver lifecycle, memory and heap health, ACPI, interrupt routing, IOMMU state and the storage controllers bound to their drivers.
What the new kernel already does
No desktop yet, by design. The rewrite is building the foundations first, and every item below is running on each boot, not just present in the source.
A versioned boot contract
A new UEFI bootloader with a Console and Normal boot menu, strict executable validation that refuses writable-and-executable memory, and a versioned handoff to the kernel that is checked before it is trusted.
Every core, fairly scheduled
All processors are discovered from ACPI and started, each with its own protected stacks and fair run queue. Idle cores steal work from the nearest neighbour first, and hybrid CPUs are identified core by core.
Devices kept in their lane
Intel VT-d and AMD-Vi IOMMUs are switched on with deny-by-default rules, so a device can only reach memory it has explicitly been given. A strict DMA layer sits between every driver and physical memory.
A managed driver core
Drivers claim devices through one standard lifecycle covering probe, removal, reset, power states and error recovery, with every resource tracked so a failed driver can be unwound cleanly.
ACPI and interrupt routing
The industry-standard ACPICA interpreter reads the firmware’s own description of the machine, and interrupts are routed through the I/O APIC and modern message-signalled interrupts.
Memory with guard rails
A slab allocator with per-core caches and red zones catches corruption at the point it happens, and the machine’s memory, processors and hardware are catalogued in a central registry.
Prototype versus rewrite
The destination has not changed. What has changed is how each boundary is defined, enforced and proven.
| Area | v0.4.1.0 prototype | Rewrite |
|---|---|---|
| Toolchain | Older C standard, pinned to an older compiler with warnings silenced | GNU C23 on GCC 15, reproducible container builds with a recorded manifest |
| Boot handoff | An unversioned structure shared by convention | A versioned, validated boot protocol |
| Memory protection | Broad early mappings, with no-execute unused | Kernel-owned page tables and enforced write-xor-execute |
| Device access | Global tables and per-machine special cases | A managed driver core, tracked I/O mappings and per-device IOMMU domains |
| Timing | Busy loops counted in CPU iterations | A calibrated clock with real timeouts and deadlines |
| Proof | It boots on my machine | Hosted unit tests, a QEMU gate, then the same image on three physical machines |
The road to v0.0.6.0
Each step has an exit gate, and a version number never overrides it. A subsystem is only complete when its failure paths work, its tests pass, and the exact same image passes on an Intel NUC, an AMD mini-PC and an AMD desktop with a discrete GPU.
| Milestone | Focus |
|---|---|
| v0.0.5.5 | Observability, safer execution and the ACPICA landing (complete) |
| v0.0.5.6 | Slab allocator, ACPI namespace, interrupt routing and an active IOMMU (current build) |
| v0.0.5.7 | ACPI platform events, power buttons and the system clock |
| v0.0.5.8 | Memory, interrupt routing and PCI completion |
| v0.0.5.9 | IOMMU activation and production-grade DMA qualification |
| v0.0.5.10 | The full fair scheduler and synchronisation primitives |
| v0.0.5.11 | UEFI runtime services and the complete power lifecycle |
| v0.0.5.12 | A dynamic hardware graph and a unified driver core |
| v0.0.5.13 | Platform release candidate and storage-readiness gate |
| v0.0.6.0 | Native AHCI 1.3.1 and NVMe 1.4 storage |
Beyond v0.0.6.0, the path retraces the prototype’s steps with stronger foundations: filesystems and the VFS, isolated user space and the MNX executable format, USB input, networking, audio, and finally the compositor and desktop, this time with the object-oriented filesystem designed in from the start.