netdev - Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <07f149f6-f8ac-96b9-350d-b289ef16d82f@solarflare.com>
Date:   Wed, 4 Nov 2020 23:05:41 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Hangbin Liu <haliu@...hat.com>, David Ahern <dsahern@...il.com>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        Andrii Nakryiko <andrii.nakryiko@...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>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 04/11/2020 22:10, Alexei Starovoitov wrote:
> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <ecree@...arflare.com> wrote:
>> On 04/11/2020 03:11, Alexei Starovoitov wrote:
>>> The user will do 'tc -V'. Does version mean anything from bpf loading pov?
>>> It's not. The user will do "ldd `which tc`" and then what?
>> Is it beyond the wit of man for 'tc -V' to output somethingabout
>>  libbpf version?
>> Other libraries seem to solve these problems all the time, I
>>  haven't seen anyone explain what makes libbpf so special that it
>>  has to be different.
> slow vger? Please see Daniel and Andrii detailed explanations.
Nah, I've seen that subthread(vger is fine).  I felt that subthread
 was missing this point about -V which is why I replied where it was
 brought up.
Daniel and Andrii have only explained why users will want to have an
 up-to-date libbpf, they (and you) haven't connected it to any
 argument about why static linking is the way to achieve that.
> libbpf is not your traditional library.
This has only been asserted, not explained.
I'm fully willing to entertain the possibility that libbpf is indeed
 special.  But if you want to win people over, you'll need to
 explain *why* it's special.
"Look at bfd and think why" is not enough, be more explicit.

AIUI the API between iproute2 and libbpf isn't changing, all that's
 happening is that libbpf is gaining new capabilities in things that
 are totally transparent to iproute2 (e.g. BTF fixups).  So the
 reasonable thing for users to expect is "I need new BPF features,
 I'll upgrade my libbpf", and with dynamic linking that works fine
 whether they upgrade iproute2 too or not.
This narrative is, on the face of it, just as plausible as "I'm
 getting an error from iproute2, I'll upgrade that".  And if distros
 decide that that's a common enough mistake to matter, then they can
 make the newer iproute2 package depend on a newer libbpf package,
 and apt or yum or whatever will automagically DTRT.
Whereas if you tightly couple them from the start, distros can't
 then go the other way if it turns out you made the wrong choice.
 (What if someone can't use the latest iproute2 release because it
 has a regression bug that breaks their use-case, but they need the
 latest libbpf for one of your shiny new features?)

Don't get me wrong, I'd love a world in which static linking was the
 norm and we all rebuilt our binaries locally every time we upgraded
 a piece.  But that's not the world we live in, and consistency
 *within* a distro matters too...

-ed