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
