On Wed, Nov 4, 2020 at 7:48 PM David Ahern <dsahern@xxxxxxxxx> wrote: > > 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). > "My experience" and "typical" don't generalize well, I'd rather not draw any specific conclusions from that. But as I replied to your last response: if you have a BPF application that doesn't use BPF CO-RE and doesn't need BTF, you'll most probably be just fine with older Clang (<v10), no one is forcing anything. We do recommend to use the latest Clang, so that you have to deal with less work arounds, of course. And you get all the shiny BTF built-ins. And some of the problematic code patterns are not generated by newer Clangs so that you as a BPF developer have to deal with less painful development and debugging process. > > > > 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. I don't think this is relevant for this discussion at all. But yes, libbpf tries to alleviate as much pain as possible. And no, extack won't help with that in general, only with some error reporting, potentially.
