KernelScript 0.1 Officially Released: A New Programming Language for eBPF Linux Kernel Development

KernelScript 0.1 Officially Released: A New Programming Language for eBPF Linux Kernel Development

A brand-new open-source DSL unifies eBPF, user-space, and kernel-space development into a single codebase — aiming to dramatically lower the barrier to eBPF programming.

KernelScript 0.1 has been officially released, marking the first publicly available version of an ambitious open-source programming language specifically designed for eBPF-centric Linux kernel development. Developed by Multikernel Technologies Inc. and licensed under the permissive Apache 2.0 open-source license, KernelScript aims to modernize eBPF application development by reducing the complexity that has long made this powerful technology difficult to adopt.

The project was presented publicly by Multikernel Technologies founder Cong Wang at the Linux Foundation’s Open Source Summit in Minnesota, where he described plain eBPF development as “miserable to write” — a sentiment shared by many Linux systems programmers who have wrestled with its steep learning curve.

KernelScript is defined as a type-safe domain-specific language (DSL) designed specifically for eBPF development scenarios. Its central promise is unification: rather than maintaining separate eBPF programs, user-space loader code, kernel module integrations, and build scripts across multiple files and codebases, developers work from a single KernelScript source file.

The language positions itself not only as a more accessible alternative to raw C-based eBPF programs, but also as easier to work with than Rust-based eBPF solutions and more versatile than tools like bpftrace. Its type system enforces correct lifecycle ordering — for instance, preventing attach() from being called before load() succeeds — catching entire categories of runtime bugs at compile time.

eBPF has become one of the most important technologies in the Linux ecosystem over the past several years, allowing developers to run verified programs safely in kernel context without touching the kernel source code. Its adoption spans a wide range of critical infrastructure use cases:

• High-performance network packet processing
• Traffic control and load balancing
• System monitoring and observability
• Security inspection and enforcement
• Performance analysis and tracing

Yet for all its power, eBPF has remained notoriously difficult to work with. Developers must deeply understand the eBPF verifier’s constraints, master BPF helper functions and map data structures, handle program loading sequences, and navigate the libbpf user-space framework — all before writing a single line of meaningful business logic.

KernelScript hides much of this infrastructure complexity behind a higher-level, more intuitive syntax, letting developers focus on what they actually want the program to do.

KernelScript 0.1 ships with support for the most common eBPF application scenarios out of the box. Using dedicated annotations, developers can target:

• XDP — high-performance network packet processing at the driver layer
• TC (Traffic Control) — flow control and network policy management
• Probe — kernel function tracing and dynamic instrumentation
• Perf Event — performance statistics and sampling

Functions annotated with @xdp, @tc, and similar decorators compile automatically to the correct target, while regular functions compile to user-space code — all from the same source file.

Data exchange between user space and eBPF programs is a central challenge in eBPF development. KernelScript treats commonly-used BPF Maps as first-class language constructs, with built-in support for:

• Hash Map
• Per-CPU Array
• LRU Map
• Pinned Map

These map types are usable directly as language-level variables, eliminating the need to write boilerplate libbpf code to set them up and share data across program boundaries. The result is significantly more concise, readable code.

Beyond the basics, KernelScript integrates several advanced eBPF capabilities directly into the language framework:

• Automatic management of Tail Call chains
• Transparent Dynptr handling
• Program lifecycle checks enforced by the type system
• struct_ops support for kernel struct-based extensibility
• Built-in kfunc integration for kernel function calls

For complex eBPF projects, these built-in abstractions can meaningfully reduce repetitive boilerplate, lower the probability of subtle errors, and improve overall development velocity.

The emergence of KernelScript arrives at a moment when the Linux kernel ecosystem is actively seeking to lower the barriers to eBPF development. With cloud-native infrastructure, observability platforms, and security tooling increasingly leaning on eBPF, the gap between the technology’s potential and the difficulty of programming it has become a genuine limiting factor for adoption.

KernelScript’s approach — a unified, type-safe, higher-level language that generates all the necessary low-level code — represents a different philosophy than existing tools. Where Rust-based eBPF solutions bring memory safety at the cost of compilation complexity, and bpftrace optimizes for quick scripting at the cost of expressiveness, KernelScript targets the broader space of full eBPF applications with a more complete language model.

Whether it can build a sufficient ecosystem and toolchain around it to gain real traction remains to be seen. But for Linux developers who have wanted to work with eBPF without diving deep into its infrastructure complexity, it is now a project worth watching closely.