On Tue, 3 Nov 2020 19:11:45 -0800, Alexei Starovoitov wrote: > When we release new version of libbpf it goes through rigorous testing. > bpftool gets a lot of test coverage as well. > iproute2 with shared libbpf will get nothing. It's the same random roll of dice. "Random roll of dice" would be true only if libbpf did incredibly bad job in keeping backward compatibility. In my experience it is not the case. Sure, a bug in retaining the compatibility may occasionally appear; after all, any software tends to contain bugs in various places. You are right that such bug may not be caught by your testing. I also believe that if there is a bug in backward compatibility reported by someone, it will be fixed (if possible). So this is really just a matter of testing, not a fundamental problem of ABI compatibility. Let the distros worry about the testing. Upstream may test (and even recommend!) certain combinations of iproute2 + libbpf, such as the latest of both at the time of testing. If distros want to use a different combination, they can and should do their own testing. If their testing reveals a bug in backward compatibility and a patch to fix it is accepted, everything will work smoothly for the distro users. Non-distro users (or small distros) may just rely on the upstream tested combination of iproute2 + libbpf. > Few years from now the situation could be different and shared libbpf would > be the most appropriate choice. But that day is not today. Interestingly, the major compatibility problems we had were with llvm updates. After llvm update while keeping the same kernel version, llvm started to emit code that the verifier did not accept. Meaning a bpf program that was previously accepted by the kernel was rejected after recompilation. This was solved by adding a translation code to libbpf (which nicely demonstrates that indeed libbpf cares about backward compatibility). Now, with dynamically linked libbpf, a single package update was able to solve the problem for everything on the system, including users' own programs. All that was needed was making the llvm package force update the libbpf package (which rpm can do easily with its Conflicts dependency). So, at least for us, there was so far no disadvantage (and no problem) with dynamic linking and a quite substantial advantage. Jiri
