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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Nov 2020 16:53:48 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        David Ahern <dsahern@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Hangbin Liu <haliu@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jiri Benc <jbenc@...hat.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

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.