KernelScript 0.1 Debuts as a Type-Safe DSL for eBPF, Unifying Kernel and Userspace Development
Multikernel Technologies releases KernelScript, an Apache 2.0-licensed DSL that generates eBPF, userspace, and kernel module code from a single source file.
Overview
Multikernel Technologies, Inc., a San Jose, California-based company working on next-generation cloud operating systems, has released KernelScript 0.1 — a new open-source, type-safe domain-specific language designed to simplify Linux kernel extension development. The initial 0.1.0 release landed on May 13, 2026, followed by a patch release to 0.1.1 on May 18. Published under the Apache 2.0 license, the project aims to unify eBPF, userspace, and kernelspace development in a single codebase.
What We Know
eBPF — Extended Berkeley Packet Filter — is a Linux kernel technology that lets small, verified programs run inside the kernel without modifying its source code. It has become foundational to observability, security, and networking tools across the Linux ecosystem, underpinning projects such as Cilium, Falco, and bpftrace. But writing eBPF programs has historically required developers to juggle multiple separate concerns: raw C code that satisfies the kernel verifier, a separate userspace loader using the libbpf library, manual setup of tail call program arrays, and intricate management of dynptr APIs. KernelScript addresses this fragmentation head-on.
According to the KernelScript repository, the language is described as “a modern, type-safe, domain-specific programming language for eBPF-centric kernel customization” that “generates the necessary C code, userspace programs, Makefiles, and kernel module integration from one source file.” The repository states the project’s long-term aim is to “become the programming language for Linux kernel customization and application-specific optimization,” leveraging eBPF and kernel function (kfunc) capabilities as alternatives to traditional interfaces like procfs and debugfs.
The language supports the major eBPF program types in active use, as detailed by Linuxiac: XDP for high-speed packet processing, TC for traffic control, probes for kernel function tracing, and perf event programs for hardware and software performance counters. Developers can also work with standard eBPF map types — hash maps, per-CPU arrays, LRU maps, and pinned maps — exposed as language-level variables that let eBPF programs and userspace code share state without manual libbpf boilerplate.
The repository highlights several distinguishing features:
- Single-file multi-target compilation automatically directs functions to the appropriate execution target — kernel or userspace — based on function attributes in a single source file.
- Automatic tail call orchestration eliminates the need for manual program array setup, a common source of complexity in eBPF programs that span multiple functions.
- Transparent dynptr integration abstracts the complex pointer management operations the eBPF verifier requires.
- Declaration-as-condition pattern for ergonomic map operations, reducing boilerplate for common lookup-and-branch patterns.
- Unified error handling using C-style integers across both eBPF and userspace contexts.
- Complete automated toolchain that generates Makefiles and loaders alongside the compiled programs.
KernelScript is implemented primarily in OCaml and had accumulated 420 GitHub stars and 20 forks at the time of the 0.1.1 release. The project lists three contributors in its initial release: jbrandeb, SiyuanSun0736, and congwang-mk.
Broader Context
KernelScript is not an isolated project. Multikernel Technologies has been building infrastructure around the concept of running multiple kernel instances on a single Linux host — the company maintains Kerf, an orchestration tool for managing multiple kernel instances; KBI, which packages Linux kernels as OCI images; and a fork of the Linux kernel with Multikernel support, according to its GitHub organization page. The company’s stated mission is delivering “the next generation of cloud operating systems with unprecedented performance.”
KernelScript fits into that vision as the developer-facing layer for customizing kernel behavior without modifying upstream source. It positions itself as a higher-level alternative to raw C with libbpf, aiming to make eBPF-based kernel customization accessible to a wider pool of developers. A commenter on Lobsters noted: “Nice, I have wanted a DSL for eBPF for years,” pointing out that existing tools like bpftrace and Ply “are only for tracing” and leave a gap for broader eBPF program development.
What We Don’t Know
The project is clearly early-stage. According to the project README, “KernelScript is currently in beta development. The language syntax, APIs, and features are subject to change at any time without backward compatibility guarantees.” Developers are advised not to use it in production environments.
Multikernel Technologies has not disclosed funding status, headcount, or a commercial roadmap. Whether the project will pursue an upstream contribution path to the Linux kernel itself — or remain a parallel toolchain — is not addressed in the public materials. Community adoption beyond the initial 420-star reception remains to be seen, and it is not yet clear whether major eBPF-based projects like Cilium or the Linux Foundation’s eBPF Foundation have taken notice.
Analysis
The problem KernelScript targets is genuine. Writing production-quality eBPF programs today requires mastery of at least three distinct programming environments: the constrained kernel-side C subset that the verifier accepts, the userspace loader code in Go or C using libbpf, and the kernel’s kfunc interface for extending the verifier’s trusted function set. Projects like bcc and bpftrace have lowered the barrier for tracing use cases, but the surface area for XDP-based network data paths, custom TCP congestion control via struct_ops, or kernel extension via kfuncs has remained largely inaccessible without deep systems expertise.
KernelScript’s single-file compilation model and automatic toolchain generation address this concretely. If the generated C code consistently satisfies the eBPF verifier in real-world programs — the central technical risk for any eBPF abstraction layer — the language could reduce the expertise barrier meaningfully. The choice of OCaml as an implementation language is consistent with the goals of strong type safety and compiler correctness, though it may affect the pool of contributors willing to work on the toolchain itself.
The project’s positioning as part of a broader multikernel operating system vision adds a longer arc worth watching: if Multikernel Technologies’ broader kernel-multiplexing infrastructure gains traction, KernelScript could become the natural programming interface for that environment.