Establishing /usr/lib/bpf as a convention for eBPF bytecode files?

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Hi everyone

As you have no doubt noticed, we have started thinking about how to
package eBPF-related applications in distributions. As a part of this,
I've been thinking about what to recommend for applications that ship
pre-compiled BPF byte-code files.

The obvious place to place those would be somewhere in the system
$LIBDIR (i.e., /usr/lib or /usr/lib64, depending on the distro). But
since BPF byte code is its own binary format, different from regular
executables, I think having a separate path to put those under makes
sense. So I'm proposing to establish a convention that pre-compiled BPF
programs be installed into /usr/lib{,64}/bpf.

This would let users discover which BPF programs are shipped on their
system, and it could be used to discover which package loaded a
particular BPF program, by walking the directory to find the file a
loaded program came from. It would not work for dynamically-generated
bytecode, of course, but I think at least some applications will end up
shipping pre-compiled bytecode files (we're doing that for xdp-tools,
for instance).

As I said, this would be a convention. We're already using it for
xdp-tools[0], so my plan is to use that as the "first mover", try to get
distributions to establish the path as a part of their filesystem
layout, and then just try to encourage packages to use it. Hopefully it
will catch on.

Does anyone have any objections to this? Do you think it is a complete
waste of time, or is it worth giving it a shot? :)

-Toke

[0] https://github.com/xdp-project/xdp-tools/blob/master/lib/defines.mk#L12