On Wed, Nov 4, 2020 at 2:24 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > > > 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 >
