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

[Edward Cree <ecree@solarflare.com>]

On 05/11/2020 14:05, Jamal Hadi Salim wrote:
> On 2020-11-04 10:19 p.m., David Ahern wrote:
>
> [..]
>> Similarly, it is not realistic or user friendly to *require* general
>> Linux users to constantly chase latest versions of llvm, clang, dwarves,
>> bcc, bpftool, libbpf, (I am sure I am missing more)
>
> 2cents feedback from a dabbler in ebpf on user experience:
>
> What David described above *has held me back*.
If we're doing 2¢... I gave up on trying to keep ebpf_asmabreast
 of all the latest BPF and BTF features quite some time ago, since
 there was rarely any documentation and the specifications for BPF
 elves were basically "whatever latest clang does".
The bpf developers seem to have taken the position that since
 they're in control of clang, libbpf and the kernel, they can make
 their changes across all three and not bother with the specs that
 would allow other toolchains to interoperate.  As a result of
 which, that belief has now become true — while ebpf_asm will
 still work for what it always did (simple XDP programs), it is
 unlikely ever to gain CO-RE support so is no longer a live
 alternative to clang for BPF in general.
Of course the bpf developers are well within their rights to not
 care about that.  But I think it illustrates why having to
 interoperate with systems outside their control and mix-and-match
 versioning of various components provides external discipline that
 is sorely needed if the BPF ecosystem is to remain healthy.
That is why I am opposed to iproute2 'vendoring' libbpf.

-ed