On Wed, Nov 18, 2020 at 06:07:38PM +0100, Toke Høiland-Jørgensen wrote: > As a response to patches adding libbpf support to iproute2, an extensive > discussion ensued about libbpf version visibility and enforcement in tools > using the library[0]. In particular, two problems came to light: > > 1. If a tool is statically linked against libbpf, there is no way for a user > to discover which version of libbpf the tool is using, unless the tool > takes particular care to embed the library version at build time and print > it. > > 2. If a tool is dynamically linked against libbpf, but doesn't use any > symbols from the latest library version, the library version used at > runtime can be older than the one used at compile time, and the > application has no way to verify the version at runtime. > > To make progress on resolving this, let's add a libbpf_version() function that > will simply return a version string which is embedded into the library at > compile time. This makes it possible for applications to unambiguously get the > library version at runtime, resolving (2.) above, and as an added bonus makes > it > easy for applications to print the library version, which should help with > (1.). > > [0] https://lore.kernel.org/bpf/[email protected]/T/#t > > Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Unless iproute2 adopts scrict libbpf.so.version == iproute2.version policy and removes legacy bpf loader no iproute2 driven changes to libbpf will be accepted. Just like the kernel doesn't add features for out-of-tree modules libbpf doesn't add features for projects where libbpf is optional.
