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.
