The future of libraries in BPF

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

Song Liu believes that the way that programmers assemble complex BPF programs will be changing rapidly in the future. At a session of the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit, he shared his thoughts on what that change could look like, though he did not have any concrete proposals for what, if anything, the BPF maintainers should do. He anticipates an ecosystem of Rust BPF packages developing, which is significant because BPF does not really have a package manager at the moment.

There are not many existing, popular BPF libraries, Liu said. Those that exist are generally small header-only libraries, or deal with the user-space side of loading and managing BPF programs. It is not impossible to have BPF libraries; bpftrace has a standard library. Bpftrace can also import non-standard-library BPF C code in a manner similar to inline assembly in normal C code. "But I'm not sure people actually do this," he added.

Given that the rest of the programming world makes use of libraries, why not BPF? There are a few reasons. For one thing, there is no standard package manager or manner of distribution. Also, whether a BPF program passes the verifier can depend on properties of the whole program taken together, not just a function in isolation. This makes using libraries harder, and many people find it easier to copy an existing example and tweak it for their use than to build a reusable library. The one obvious exception to this trend is libarena, which was discussed earlier in the summit.

Emil Tsalapatis pointed out that another reason for the lack of libraries may be that many people write BPF programs as a single C file, and don't go through the steps required to link multiple BPF objects. He has observed that pattern when dealing with sched_ext schedulers, for example.

With Alexei Starovoitov planning on making BPF easier to write in Rust, there is the possibility that BPF libraries could start appearing on crates.io, Rust's package repository, Liu said. But that has its own problems: with many libraries, it can be hard to find the good, reliable ones. Also, libarena may change substantially if it is rewritten in Rust. Starovoitov clarified that libarena is written in C for now, "but we'll just convert it to Rust" when the time comes.

Liu then speculated about how the use of large language models (LLMs) might change the picture around the use of BPF libraries. He thinks they may be even more prone to copying and modifying existing solutions than human authors, but it is hard to be sure. Liu's prediction is that more BPF libraries will appear on crates.io; great libraries will remain as libraries, where merely good libraries will be copied, pasted, and modified. Bad libraries will cause problems and take time to convert into useful code. A lot of that prediction depends on how well LLMs adapt to changes in BPF's packaging culture, however.

Starovoitov said that he expects LLMs to quickly adapt to the use of libarena specifically. A copy of the library should be kept on GitHub, he said. Then sched_ext can include it as a Git submodule, and once LLMs "scrape the repo for the millionth time" they'll pick up on what has been moved into libarena code and start using it. As of July 2026, sched_ext has not yet added libarena as a submodule. In general, putting libraries into the places that LLMs know to look for them, such as GitHub, crates.io, etc., will help with adoption, Starovoitov said.

Liam Wiseheart asked what people expected to put in BPF libraries, other than basic data structures. "Whatever you want," Starovoitov answered. Some candidate answers were ventured by other attendees, including path printing and traversal, string manipulation, basic file globbing, and regular expressions.