On Wed, 4 Nov 2020 14:12:47 +0100 Daniel Borkmann wrote: > If we would have done lib/bpf.c as a dynamic library back then, we wouldn't be > where we are today since users might be able to start consuming BPF functionality > just now, don't you agree? This was an explicit design choice back then for exactly > this reason. If we extend lib/bpf.c or import libbpf one way or another then there > is consistency across distros and users would be able to consume it in a predictable > way starting from next major releases. And you could start making this assumption > on all major distros in say, 3 months from now. The discussion is somehow focused > on the PoV of /a/ distro which is all nice and good, but the ones consuming the > loader shipping software /across/ distros are users writing BPF progs, all I'm > trying to say is that the _user experience_ should be the focus of this discussion > and right now we're trying hard making it rather painful for them to consume it. IIUC you're saying that we cannot depend on libbpf updates from distro. Isn't that a pretty bad experience for all users who would like to link against it? There are 4 components (kernel, lib, tools, compiler) all need to be kept up to date for optimal user experience. Cutting corners with one of them leads nowhere medium term IMHO. Unless what you guys are saying is that libbpf is _not_ supposed to be backward compatible from the user side, and must be used a submodule. But then why bother defining ABI versions, or build it as an .so at all. I'm also confused by the testing argument. Surely the solution is to add unit / system tests for iproute2. Distros will rebuild packages when dependencies change and retest. If we have 0 tests doesn't matter what update strategy there is.
