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
