This is the canonical implementation checklist for flow-kernel after moving away from a bespoke kernel and onto Tiny Core CorePure64 + Linux.
The goal is to keep the substrate tiny, let Linux own commodity kernel machinery, and concentrate Flow work on kernel-facing systems code and a first-class eBPF toolchain.
Phase 0 — land and validate the Tiny Core migration
Phase 1 — define the Flow/Linux systems boundary
Phase 1.5 — deterministic Linux system-health sequence
Phase 2 — introduce a real Flow eBPF compilation target
Phase 3 — eBPF program model and helpers
Phase 4 — BTF and CO-RE
Phase 5 — tracing hooks
Phase 6 — networking hooks
Phase 7 — loader and userspace control plane
Phase 8 — Tiny Core packaging
Phase 9 — hardening and performance
Phase 10 — developer experience
Phase 11 — release criteria
Current diagnostic baseline
Known-good QEMU profile: Tiny Core CorePure64 17.1, Linux 6.18.35-tinycore64, x86_64 TCG, 256 MiB. The latest strict run passed the complete required system-health sequence, regression comparison, reboot and poweroff paths. DNS remains an intentional advisory/degraded result in the rdinit diagnostic environment. Runtime BPF capability is proven; upstream BTF/config metadata retrieval remains unresolved and is deliberately tracked separately above.
Guiding constraint
Do not reimplement Linux kernel infrastructure unless there is a Flow-specific research reason to do so. Linux owns boot, VM, scheduling, interrupts, drivers, networking and the eBPF VM/verifier. flow-kernel should own the Flow-facing systems layer, eBPF compilation/runtime integration, tiny userspace services and reproducible Tiny Core packaging.
This is the canonical implementation checklist for
flow-kernelafter moving away from a bespoke kernel and onto Tiny Core CorePure64 + Linux.The goal is to keep the substrate tiny, let Linux own commodity kernel machinery, and concentrate Flow work on kernel-facing systems code and a first-class eBPF toolchain.
Phase 0 — land and validate the Tiny Core migration
codex/tiny-core-basetinycore/fetch.shagainst the pinned CorePure64 releasetinycore/run.shboots successfully under QEMUPhase 1 — define the Flow/Linux systems boundary
write,exit,mmap,clock_gettimeand file descriptorsflow-kernelvsflooooooooooow/flowPhase 1.5 — deterministic Linux system-health sequence
Phase 2 — introduce a real Flow eBPF compilation target
--target bpfel/ equivalent compiler target contract in Flowllvm-objdump/llvm-readelfPhase 3 — eBPF program model and helpers
SEC("...")-equivalent section assignment from FlowPhase 4 — BTF and CO-RE
vmlinux.h-style generation/import path for FlowPhase 5 — tracing hooks
Phase 6 — networking hooks
Phase 7 — loader and userspace control plane
Phase 8 — Tiny Core packaging
.tczextensions.tczPhase 9 — hardening and performance
Phase 10 — developer experience
flow ebpf buildflow ebpf loadflow ebpf attachflow ebpf detachflow ebpf inspectPhase 11 — release criteria
flow-kernelreleaseCurrent diagnostic baseline
Known-good QEMU profile: Tiny Core CorePure64 17.1, Linux
6.18.35-tinycore64, x86_64 TCG, 256 MiB. The latest strict run passed the complete required system-health sequence, regression comparison, reboot and poweroff paths. DNS remains an intentional advisory/degraded result in therdinitdiagnostic environment. Runtime BPF capability is proven; upstream BTF/config metadata retrieval remains unresolved and is deliberately tracked separately above.Guiding constraint
Do not reimplement Linux kernel infrastructure unless there is a Flow-specific research reason to do so. Linux owns boot, VM, scheduling, interrupts, drivers, networking and the eBPF VM/verifier.
flow-kernelshould own the Flow-facing systems layer, eBPF compilation/runtime integration, tiny userspace services and reproducible Tiny Core packaging.