On Tue, Nov 10, 2020 at 12:47:28PM +0000, Edward Cree wrote: > 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. I think thriving public bpf projects, startups and established companies that are obviously outside of control of few people that argue here would disagree with your assessment.
