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

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 04 Nov 2020 23:35:26 +0100

Alexei Starovoitov <[email-masked]> writes:

> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <[email-masked]> 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.
>
> libbpf is not your traditional library.
> Looking through the installed libraries on my devserver in /lib64/ directory
> I think the closest is libbfd.so
> Then think why gdb always statically links it.

The distinguishing feature is the tool, not the library. For a tool that
intimately depends detailed behaviour, sure it makes sense to statically
link to know exactly which version you have. But for BPF, that is
bpftool, not iproute2.

For iproute2, libbpf serves a very simple function: load a BPF program
from an object file and turn it into an fd that can be attached. For
that, dynamic linking is the right thing to do so library upgrades can
bring in new support without touching the tool itself.

Daniel's example from upthread illustrates it:

bpftool prog load | tc attach

i.e., decoupling load from attach. Which is *exactly* what dynamic
linking in iproute2 would mean, except using ld(1) instead of a pipe!

-Toke