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

[Edward Cree <ecree@solarflare.com>]

On 11/11/2020 00:53, Alexei Starovoitov wrote:
> On Tue, Nov 10, 2020 at 12:47:28PM +0000, Edward Cree wrote:
>> 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.

Correct me if I'm wrong, but aren't those bpf projects and companies
 _things that are written in BPF_, rather than alternative toolchain
 components for compiling, loading and otherwise wrangling BPF once
 it's been written?
It is the latter that I am saying is needed in order to keep BPF
 infrastructure development "honest", rather than treating the clang
 frontend as The API and all layers below it as undocumented internal
 implementation details.
In a healthy ecosystem, it should be possible to use a compiler,
 assembler, linker and loader developed separately by four projects
 unrelated to each other and to the kernel and runtime.  Thanks to
 well-specified ABIs and file formats, in the C ecosystem this is
 actually possible, despite the existence of some projects that
 bundle together multiple components.
In the BPF ecosystem, instead, it seems like the only toolchain
 anyone cares to support is latest clang + latest libbpf, and if you
 try to replace any component of the toolchain with something else,
 the spec you have to program against is "Go and read the LLVM
 source code, figure out what it does, and copy that".
That is not sustainable in the long term.

-ed