By ByteBot
eBPF is one of the most powerful technologies in Linux infrastructure today — used by Cloudflare to stop terabit-scale DDoS attacks, by Datadog and Pixie for zero-instrumentation observability, and by Amazon’s EKS as the default container networking layer. The problem has never been what eBPF can do. The problem is what you have to go through to write it: C code for the kernel program, a separate userspace loader full of libbpf boilerplate, hand-rolled Makefiles, and kernel module glue code — all maintained as disconnected files in a language with the memory safety of a paper bag. KernelScript 0.1, which debuted at the Linux Foundation Open Source Summit North America this week in Minneapolis, is a new type-safe DSL that collapses all of that into a single source file.
One File, Everything Generated
The core idea is straightforward. You write one .ks source file. KernelScript compiles it and generates the eBPF C code, the coordinated userspace program, the Makefile, and the kernel module integration code. What used to be a four-component project managed in multiple languages becomes a single coherent source.
eBPF maps — the shared state mechanism between kernel and userspace programs — are first-class language-level variables in KernelScript. Hash maps, per-CPU arrays, LRU maps, and pinned maps are available without touching libbpf directly. The boilerplate that consumes roughly 40% of a typical eBPF project just disappears.
KernelScript covers the major eBPF program types: XDP for packet processing, TC for traffic control, probes for kernel function tracing, and perf event programs for performance counters. Advanced features — automatic tail call orchestration, transparent dynptr handling, struct_ops support, and built-in kfunc integration — are included without requiring developers to wire them up manually.
A Type System That Catches eBPF Bugs at Compile Time
The more interesting part of KernelScript is what its type system enforces. eBPF programs have a specific lifecycle: you load, then you attach. Calling attach() before load() succeeds is a common runtime bug — one that surfaces as a confusing failure rather than a clear error. KernelScript makes this a compile-time error. The type system enforces correct lifecycle ordering, catching an entire category of bugs before the program ever runs.
It also handles BTF extraction automatically. BTF (BPF Type Format) is the metadata layer that enables CO-RE — the “compile once, run everywhere” portability that lets an eBPF program load on different kernel versions without recompilation. Getting BTF right manually is a non-trivial task. KernelScript generates it for you.
Where KernelScript Fits in the eBPF Ecosystem
The eBPF tooling landscape has three main tiers. At the top, bpftrace offers high-level tracing scripts — fast to write, but limited to tracing, and missing kfuncs, many map types, and any kernel module capability. At the bottom, raw C with libbpf gives you full control and maximum pain. In the middle, Rust eBPF via Aya or libbpf-rs offers type safety and ecosystem integration — but requires learning Rust and eBPF at the same time, which is a steep double barrier for most teams.
KernelScript targets the gap none of these fills well: developers who know Linux and need non-trivial eBPF programs — beyond what bpftrace handles — but who are not kernel C developers by trade and do not want to onboard an entire Rust stack to get there. Platform engineers, systems administrators, and DevOps teams writing custom eBPF for observability or security are the target audience. That is a real and growing segment.
Beta Means Beta
Multikernel Technologies is straightforward about where this stands: experimental, beta, not production-ready. The repository explicitly warns that syntax, APIs, and features may change without backward compatibility. If you write KernelScript code today, expect to update it as the language evolves. Apache 2.0 licensing makes experimentation commitment-free — but this is not the tool for production infrastructure in its current state.
What it is suitable for: exploring the approach, evaluating whether it fits your team’s skill set, and contributing to an open-source project at the ground floor. The problem KernelScript is solving is real and growing. CNCF’s Q1 2026 data shows 300% year-over-year growth in production eBPF adoption. More teams will write eBPF programs. Better tooling for those teams is not a niche concern.
Try It or Watch It Mature
If you are a platform engineer or systems developer who has wanted to write eBPF but found the C toolchain prohibitive, KernelScript is worth an afternoon of exploration. The GitHub repository includes examples, the Apache 2.0 license means zero commitment, and the single-file approach makes the project immediately approachable. If you need production-grade eBPF today, stay with the established eBPF toolchain and monitor KernelScript’s progress. Either way, the developer experience problem is actively being solved — the question is which approach gets there first.
