axiom § 02 / docs · introduction
§ introduction

Roadmap & thesis

What axiomOS is trying to prove next, and the order the work happens in.

The goal is not to expand scope. It is to finish the strongest version of the thesis already present in the codebase:

axiomOS is a runtime-programmable kernel whose behavior can be changed on a running system by loading verified programs — without reflashing or rebooting.

There is a dedicated, visual roadmap page with the full milestone ladder and phase plan. This doc is the short written version.

What already works

  • Bootable kernel on x86_64, aarch64/RPi5, and riscv64 (boot only)
  • BPF loader, verifier, interpreter, JIT, and maps
  • Timer, GPIO, syscall-entry/exit, and scheduler hooks executing on live hardware
  • Ring-buffer infrastructure and a userspace bridge scaffold
  • Hardware benchmark results on Raspberry Pi 5 — see benchmarks

The one claim left to prove

A verified program, loaded into a running kernel, attached to a real kernel event, changing behavior in a way that is visible and measurable — all the way out to a robotics ROS2 topic, with no reboot. The target demo flow is:

runtime-loaded verified program
  → live scheduler / syscall hook
  → ring buffer
  → rk-bridge
  → /rk/* ROS2 topic

Phase order

  1. Define the hook model — done. See hook model.
  2. Live scheduler hooks — done. sched_switch fires in the real scheduler path on RPi5.
  3. Real syscall hook interface — done. Entry/exit split, result code on exit.
  4. The no-reboot demo — in progress. Kernel-side handoff (Pass 1) and pinned-object export (Pass 2A) are validated on hardware; bridge integration and real ROS2 publishing remain.
  5. Measure hook overhead — planned. Matched RPi5 latency with and without active hooks.
  6. Reduce kernel heap below 10 MB — planned. Currently ~12.3 MB at init.
  7. Complete rk-bridge ROS2 publishing — planned, may proceed in parallel, but the demo only counts when fed by live kernel events.

What we will not do yet

Networking-stack expansion, a Copper-like runtime, broad benchmark expansion before the hook work lands, and major subsystems unrelated to runtime programmability. These may matter later; none is the bottleneck now.

← All docs Edit on GitHub ↗