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

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Wed, Nov 11, 2020 at 11:31:47AM +0000, Edward Cree wrote:
> 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.

Absolutely. I agree 100% with above.
BPF ecosystem eventually will get to a point of fixed file format,
linker specification and 1000 page psABI document.
One can argue that when RISCV ISA was invented recently and it came with full
ABI document just like x86 long ago. BPF ISA is different. It grows
"organically". We don't add all possible instructions up front. We don't define
all possible relocation types to ELF. That fundamental difference vs all other
ISAs help BPF follow its own path. Take BTF, for example. No other ISA have
such concept. Yet due to BTF the BPF ecosystem can provide features no other
ISA can. Similar story happens with clang. BPF extended C language _already_.
The BPF C programs have a way to compare types. It is a C language extension.
Did we go to C standard committee and argue for years that such extension is
necessary? Obviously not. Today BPF is, as you correctly pointed out, layers of
undocumented internal details. Obviously we're not content with such situation.