The future of libraries in BPF [LWN.net]

LWN<br>.net<br>News from the source

Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments

LWN FAQ<br>Write for us

Edition Return to the Front page

User:<br>Password: |

Log in /<br>Subscribe /<br>Register

The future of libraries in BPF

For humans, by humans

Every article on LWN.net is written for humans, by humans. If you've<br>enjoyed this article and want to see more like it, your subscription goes a<br>long way to keeping the slop at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.

By Daroc Alden<br>July 31, 2026

LSFMM+BPF

Song Liu believes that the way that programmers assemble complex BPF programs<br>will be changing rapidly in the future.<br>At a session of the 2026

Linux Storage,<br>Filesystem, Memory-Management, and BPF Summit, he shared his thoughts on what<br>that change could look like, though he did not have any concrete proposals for<br>what, if anything, the BPF maintainers should do. He anticipates an<br>ecosystem of Rust BPF packages developing, which is significant because BPF<br>does not really have a package manager at the moment.

There are not many existing, popular BPF libraries, Liu said. Those that exist<br>are generally small header-only libraries, or deal with the user-space side of<br>loading and managing BPF programs. It is not impossible to have BPF libraries;

bpftrace has a standard library. Bpftrace can also import<br>non-standard-library BPF C code in a manner similar<br>to inline assembly in normal C code. "But I'm not sure people actually do<br>this," he added.

Given that the rest of the programming world makes use of libraries, why not<br>BPF? There are a few reasons. For one thing, there is no standard package<br>manager or manner of distribution. Also, whether a BPF program passes the<br>verifier can depend on properties of the whole program taken together, not just<br>a function in isolation. This makes using libraries harder, and<br>many people find it easier to copy an existing<br>example and tweak it for their use than to build a reusable library. The<br>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<br>that many people write BPF programs as a single C file, and don't go through the<br>steps required to link multiple BPF objects. He has observed that pattern when dealing<br>with sched_ext schedulers, for example.

With Alexei Starovoitov

planning on making BPF easier to write in Rust, there<br>is the possibility that BPF libraries could start appearing on

crates.io,<br>Rust's package repository, Liu said. But that has its own problems: with many<br>libraries, it can be hard to find the good, reliable ones. Also, libarena may<br>change substantially if it is rewritten in Rust. Starovoitov clarified that<br>libarena is written in C for now, "but we'll just convert it to Rust"<br>when the time comes.

Liu then speculated about how the use of large language models (LLMs) might<br>change the picture around the use of BPF libraries. He thinks they may be even<br>more prone to copying and modifying existing solutions than human authors, but<br>it is hard to be sure. Liu's prediction is that more BPF libraries will<br>appear on crates.io; great libraries will remain as libraries, where merely good<br>libraries will be copied, pasted, and modified. Bad libraries will cause problems<br>and take time to convert into useful code. A lot of that prediction depends on<br>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<br>specifically. A copy of the library should be kept on GitHub, he<br>said. Then sched_ext can include it as a Git submodule, and once LLMs "scrape the<br>repo for the millionth time" they'll pick up on what has been moved into<br>libarena code and start using it. As of July 2026, sched_ext has not yet added<br>libarena as a submodule.<br>In general, putting libraries into the places<br>that LLMs know to look for them, such as GitHub, crates.io, etc., will help with<br>adoption, Starovoitov said.

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

Index entries for this article<br>ConferenceStorage, Filesystem, Memory-Management and BPF Summit/2026

to post comments

Userspace / BPF delegation

Posted Jul 31, 2026 22:33 UTC (Fri)<br>by RazeLighter777 (subscriber, #130021)<br>[Link]

It is interesting. BPF libraries seem like they could be useful, but in most use cases I've had, the complex logic

is best moved into userspace, with BPF serving as the shim between the two, with BPF having many existing

options for BPF/userspace communication.

But perhaps this was a hack over the strictness of the verifier,...