Plan / research kernel · seeking collaborators

The kernel that
never needs reflashing.

axiomOS is a research project with one north star: prove that a kernel's behavior can be changed safely on a running machine. Below is the honest state of that effort — what's shipped, what's next, and the numbers we're holding ourselves to. The long-term home for this work is an academic submission (ASPLOS AgenticOS) and an open ecosystem for robotics.

§ 01 / milestones shipped
Pi5 bring-up · M1–M4 closed
  1. M1 ■ done
    Pi5 boot stability
    Reproducible marker progression with no panic
  2. M2 ■ done
    Block device + rootfs mount
    Root filesystem mounts, PID 1 scheduled
  3. M3 ■ done
    Userspace benchmark on Pi5
    /bin/benchmark prints full telemetry
  4. M4 ■ done
    Matched Axiom vs Linux table
    5-run measurements, 10× latency improvement
§ 02 / execution phases
critical path + parallel bridge track

One claim left to make undeniable.

The thesis demo is a single visible flow: runtime-loaded program → live kernel hook → ring buffer → rk-bridge → /rk/* ROS2 topic. Each layer has value alone; together they are the whole argument.

  1. 01

    Define the runtime hook model

    ■ done

    Turn the collection of attach points into a clear contract: which hooks exist, what context each provides, what a program may and may not change. The minimum set — timer, gpio, sys_enter, sys_exit, sched_switch — is named consistently across kernel, docs, and tooling.

    • 7 attach types live
    • BpfContext wrapper defined
    • observe-only semantics documented
  2. 02

    Finish live scheduler hooks

    ■ done

    Wire BPF execution into the real scheduler path so a running kernel runs verified programs during actual task switches on hardware — not a synthetic test path.

    • sched_switch fires in reschedule()
    • read-only scheduling context
    • validated on RPi5
  3. 03

    Upgrade syscall hooks into a real interface

    ■ done

    Split entry and exit hooks, expose the result code on exit, and make targeting specific syscalls possible. Easy to explain, easy to benchmark, a direct answer to 'what changes on a running kernel?'

    • sys_enter + sys_exit split
    • exit context carries result
    • stable context structs
  4. 04

    Build the main no-reboot demo

    ◧ in progress

    One short, obvious demo: a running kernel changes its behavior because a verified program was loaded and attached live — all the way out to a robotics ROS2 topic. Pass 1 (in-kernel handoff) and Pass 2A (pinned objects) are validated on RPi5; remaining work is bridge integration and real ROS2 publication.

    • Pass 1: shared map-id handoff ✓
    • Pass 2A: pinned object export ✓
    • bridge + ROS2 publish — in progress
  5. 05

    Measure the cost of programmability

    □ planned

    Quantify hook overhead with matched RPi5 measurements: baseline syscall latency, latency with an empty hook, latency with a real hook, against the Linux baseline.

    • sys_write / sys_read / sys_getpid
    • with vs without active hook
    • reproducible, commit-pinned
  6. 06

    Reduce kernel heap below 10 MB

    □ planned

    Meet the proposal footprint target. Current init heap on RPi5 is ~12.3 MB. Measurement-driven: find the largest allocators, separate one-time setup from persistent footprint, trim where safe.

    • profile init allocators
    • target < 10 MB at init
    • tradeoffs recorded
  7. 07

    Complete the rk-bridge ROS2 publishing

    □ planned

    Finish the bridge from live kernel events to actual ROS2 topics, making axiomOS legible to robotics developers. Real RosPublisher behind the ros2 feature, IMU / motor / safety events on /rk/*.

    • implement RosPublisher
    • stable event → topic mapping
    • fed only by live kernel events
§ 03 / targets we hold ourselves to
measured on RPi5
metric target stretch actual verdict
Kernel memory footprint <10 MB <5 MB ~22 MB ○ open
Boot to init <1 s <500 ms 99 ms ✓ met
BPF load time <10 ms <1 ms ~0 µs ✓ met
Interrupt latency <10 µs <1 µs 211 ns ✓ met
Programs shipped 10 examples 50 examples 2 built-in ○ open

Footprint and example-library targets remain open — deliberately, after thesis-critical work.

§ 04 / who this is for

Collaborators

A real kernel that boots on real hardware. If you work on kernel safety, runtime-programmable systems, or novel OS architectures — there's integration and validation work to do together.

Robotics teams

If you're frustrated by frozen Linux kernels on devices you can't safely update, axiomOS wants real-world validation. Bring a workload.

Researchers

Streaming O(n) verification, a runtime-programmable kernel architecture, and kernel-level safety enforcement for robotics — all open questions worth a paper.