From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: daniel@iogearbox.net, ast@fb.com, andrii@kernel.org,
bpf@vger.kernel.org, netdev@vger.kernel.org, brouer@redhat.com,
haliu@redhat.com, dsahern@gmail.com, jbenc@redhat.com
Subject: Re: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
Date: Wed, 18 Nov 2020 19:01:01 +0100 [thread overview]
Message-ID: <87zh3e1r4y.fsf@toke.dk> (raw)
In-Reply-To: <20201118174325.zjomd2gvybof6awa@ast-mbp>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> 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/20201109070802.3638167-1-haliu@redhat.com/T/#t
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> 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.
This is not a iproute2-specific feature, though. It came out of the
iproute2 discussion, sure, but it's a generic helper to get the library
version for any application that wants to use it.
In particular, I am planning to use this in the xdp-tools binaries:
$ ./xdpdump --version
xdpdump version 1.0.1 using libbpf version 0.3.0
-Toke
next prev parent reply other threads:[~2020-11-18 18:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 17:07 [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime Toke Høiland-Jørgensen
2020-11-18 17:43 ` Alexei Starovoitov
2020-11-18 18:01 ` Toke Høiland-Jørgensen [this message]
2020-11-19 8:56 ` Jiri Benc
2020-11-18 21:16 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zh3e1r4y.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=haliu@redhat.com \
--cc=jbenc@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.