On Wed, Nov 4, 2020 at 2:24 PM Toke Høiland-Jørgensen [off-list ref] wrote:

Andrii Nakryiko [off-list ref] writes:

quoted

Some of the most important APIs of libbpf are, arguably,
bpf_object__open() and bpf_object__load(). They accept a BPF ELF file,
do some preprocessing and in the end load BPF instructions into the
kernel for verification. But while API doesn't change across libbpf
versions, BPF-side code features supported changes quite a lot.

Yes, which means that nothing has to change in iproute2 *at all* to get
this; not the version, not even a rebuild: just update the system
libbpf, and you'll automatically gain all these features. How is that an
argument for *not* linking dynamically? It's a user *benefit* to not
have to care about the iproute2 version, but only have to care about
keeping libbpf up to date.

I mean, if iproute2 had started out by linking dynamically against
libbpf (setting aside the fact that libbpf didn't exist back then), we
wouldn't even be having this conversation: In that case its support for
new features in the BPF format would just automatically have kept up
along with the rest of the system as the library got upgraded...

I think it's a difference in the perspective.

You are seeing iproute2 as an explicit proxy to libbpf. Users should
be aware of the fact that iproute2 just uses libbpf to load whatever
BPF ELF file user provides. At that point iproute2 versions almost
doesn't matter. Whatever BPF application users provide (that rely on
iproute2 to load it) should still be very conscious about libbpf
version and depend on that explicitly.

I saw it differently. For me, the fact that iproute2 is using libbpf
is an implementation detail. User developing BPF application is
providing a BPF ELF file that follows a de facto BPF "spec" (all those
SEC() conventions, global variables, map references, etc). Yes, that
"spec" is being driven by libbpf currently, but libbpf is not the only
library that supports it. Go BPF library is trying to keep up and
support most of the same features. So in that sense, iproute2 is
another BPF loader, just like Go library and libbpf library. The fact
that it defers to libbpf should be not important to the end user. With
that view, if a user tested their BPF program with a specific iproute2
version, it should be enough.

But clearly that's not the view that most people on this thread hold
and prefer end users to know and care about libbpf versioning
explicitly. That's fine.

But can we at least make sure that when libbpf is integrated with
iproute2, it specifies the latest libbpf (v0.2) as a dependency?

-Toke