Message-ID: <dba0723f-fd55-5dd6-dccc-4e0a649c860e@gmail.com>
Date:   Wed, 4 Nov 2020 20:48:31 -0700
From:   David Ahern <dsahern@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.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>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 11/4/20 1:43 PM, Andrii Nakryiko wrote:
> 
> What users writing BPF programs can expect from iproute2 in terms of
> available BPF features is what matters. And by not enforcing a
> specific minimal libbpf version, iproute2 version doesn't matter all
> that much, because libbpf version that iproute2 ends up linking
> against might be very old.
> 
> There was a lot of talk about API stability and backwards
> compatibility. Libbpf has had a stable API and ABI for at least 1.5
> years now and is very conscious about that when adding or extending
> new APIs. That's not even a factor in me arguing for submodules. I'll
> give a few specific examples of libbpf API not changing at all, but
> how end user experience gets tremendously better.
> 
> Some of the most important APIs of libbpf are, arguably,
> bpf_object__open() and bpf_object__load(). They accept a BPF ELF file,
> do some preprocessing and in the end load BPF instructions into the
> kernel for verification. But while API doesn't change across libbpf
> versions, BPF-side code features supported changes quite a lot.
> 
> 1. BTF sanitization. Newer versions of clang would emit a richer set
> of BTF type information. Old kernels might not support BTF at all (but
> otherwise would work just fine), or might not support some specific
> newer additions to BTF. If someone was to use the latest Clang, but
> outdated libbpf and old kernel, they would have a bad time, because
> their BPF program would fail due to the kernel being strict about BTF.
> But new libbpf would "sanitize" BTF, according to supported features
> of the kernel, or just drop BTF altogether, if the kernel is that old.
> 

In my experience, compilers are the least likely change in a typical
Linux development environment. BPF should not be forcing new versions
(see me last response).

> 
> 2. bpf_probe_read_user() falling back to bpf_probe_read(). Newer
> kernels warn if a BPF application isn't using a proper _kernel() or
> _user() variant of bpf_probe_read(), and eventually will just stop
> supporting generic bpf_probe_read(). So what this means is that end
> users would need to compile to variants of their BPF application, one
> for older kernels with bpf_probe_read(), another with
> bpf_probe_read_kernel()/bpf_probe_read_user(). That's a massive pain
> in the butt. But newer libbpf versions provide a completely
> transparent fallback from _user()/_kernel() variants to generic one,
> if the kernel doesn't support new variants. So the instruction to
> users becomes simple: always use
> bpf_probe_read_user()/bpf_probe_read_kernel().
> 

I vaguely recall a thread about having BPF system call return user
friendly messages, but that was shot down. I take this example to mean
the solution is to have libbpf handle the quirks and various changes
which means that now libbpf takes on burden - the need for constant
updates to handle quirks. extack has been very successful at making
networking configuration mistakes more user friendly. Other kernel
features should be using the same kind of extension.

Powered by blists - more mailing lists