netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: daniel@iogearbox.net, ast@fb.com, andrii@kernel.org
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, brouer@redhat.com,
	haliu@redhat.com, dsahern@gmail.com, jbenc@redhat.com
Subject: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
Date: Wed, 18 Nov 2020 18:07:38 +0100	[thread overview]
Message-ID: <20201118170738.324226-1-toke@redhat.com> (raw)

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>
---
 tools/lib/bpf/Makefile   |  1 +
 tools/lib/bpf/libbpf.c   | 12 ++++++++++++
 tools/lib/bpf/libbpf.h   |  1 +
 tools/lib/bpf/libbpf.map |  1 +
 4 files changed, 15 insertions(+)

diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 5f9abed3e226..c9999e09a0c8 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -107,6 +107,7 @@ override CFLAGS += -Werror -Wall
 override CFLAGS += $(INCLUDES)
 override CFLAGS += -fvisibility=hidden
 override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
+override CFLAGS += -DLIBBPF_VERSION="$(LIBBPF_VERSION)"
 
 # flags specific for shared library
 SHLIB_FLAGS := -DSHARED -fPIC
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 313034117070..dc7bb3001fa6 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -136,6 +136,18 @@ static void pr_perm_msg(int err)
 
 #define STRERR_BUFSIZE  128
 
+#ifndef LIBBPF_VERSION
+#define LIBBPF_VERSION unset
+#endif
+#define __str(s) #s
+#define _str(s) __str(s)
+static const char *_libbpf_version = _str(LIBBPF_VERSION);
+
+const char *libbpf_version(void)
+{
+	return _libbpf_version;
+}
+
 /* Copied from tools/perf/util/util.h */
 #ifndef zfree
 # define zfree(ptr) ({ free(*ptr); *ptr = NULL; })
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 6909ee81113a..d8256bc1e02e 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -45,6 +45,7 @@ enum libbpf_errno {
 };
 
 LIBBPF_API int libbpf_strerror(int err, char *buf, size_t size);
+LIBBPF_API const char *libbpf_version(void);
 
 enum libbpf_print_level {
         LIBBPF_WARN,
diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
index 29ff4807b909..5f931bf1b5b0 100644
--- a/tools/lib/bpf/libbpf.map
+++ b/tools/lib/bpf/libbpf.map
@@ -345,4 +345,5 @@ LIBBPF_0.3.0 {
 		btf__parse_split;
 		btf__new_empty_split;
 		btf__new_split;
+                libbpf_version;
 } LIBBPF_0.2.0;
-- 
2.29.2


             reply	other threads:[~2020-11-18 17:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18 17:07 Toke Høiland-Jørgensen [this message]
2020-11-18 17:43 ` [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime Alexei Starovoitov
2020-11-18 18:01   ` Toke Høiland-Jørgensen
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=20201118170738.324226-1-toke@redhat.com \
    --to=toke@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).