Date:   Thu, 5 Nov 2020 12:14:21 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.com>,
        David Ahern <dsahern@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jiri Benc <jbenc@...hat.com>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

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

Powered by blists - more mailing lists