netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
@ 2020-11-18 17:07 Toke Høiland-Jørgensen
  2020-11-18 17:43 ` Alexei Starovoitov
  2020-11-18 21:16 ` David Ahern
  0 siblings, 2 replies; 5+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-11-18 17:07 UTC (permalink / raw)
  To: daniel, ast, andrii
  Cc: Toke Høiland-Jørgensen, bpf, netdev, brouer, haliu,
	dsahern, jbenc

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


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
  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
  2020-11-19  8:56   ` Jiri Benc
  2020-11-18 21:16 ` David Ahern
  1 sibling, 2 replies; 5+ messages in thread
From: Alexei Starovoitov @ 2020-11-18 17:43 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: daniel, ast, andrii, bpf, netdev, brouer, haliu, dsahern, jbenc

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
  2020-11-18 17:43 ` Alexei Starovoitov
@ 2020-11-18 18:01   ` Toke Høiland-Jørgensen
  2020-11-19  8:56   ` Jiri Benc
  1 sibling, 0 replies; 5+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-11-18 18:01 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: daniel, ast, andrii, bpf, netdev, brouer, haliu, dsahern, jbenc

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
  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 21:16 ` David Ahern
  1 sibling, 0 replies; 5+ messages in thread
From: David Ahern @ 2020-11-18 21:16 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, daniel, ast, andrii
  Cc: bpf, netdev, brouer, haliu, jbenc

On 11/18/20 10:07 AM, 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>
> ---
>  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;
> 

a good export for libraries in general to track not just the compiled
against version, but the run time version. It would be good to have the
option to add the git hash of the top commit to LIBBPF_VERSION as well
to make it easier to track dev builds.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] libbpf: Add libbpf_version() function to get library version at runtime
  2020-11-18 17:43 ` Alexei Starovoitov
  2020-11-18 18:01   ` Toke Høiland-Jørgensen
@ 2020-11-19  8:56   ` Jiri Benc
  1 sibling, 0 replies; 5+ messages in thread
From: Jiri Benc @ 2020-11-19  8:56 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Toke Høiland-Jørgensen, daniel, ast, andrii, bpf,
	netdev, brouer, haliu, dsahern

On Wed, 18 Nov 2020 09:43:25 -0800, Alexei Starovoitov wrote:
> Just like the kernel doesn't add features for out-of-tree modules
> libbpf doesn't add features for projects where libbpf is optional.

A more fitting comparison would be the kernel refusing to add a new
uAPI call because some application refuses to bundle the kernel.
A libbpf equivalent of a kernel module would be some kind of libbpf
plugin (which does not exist), asking for an internal libbpf API to be
added.

Alexei, could you please start cooperating with others and actually
listening to others' needs? I know you started eBPF but you're not the
only user anymore and as much convinced you may be about your view,
people have reasons for what they're doing. It would help greatly if
you could listen to these reasons.

 Jiri


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-11-19  8:56 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2020-11-19  8:56   ` Jiri Benc
2020-11-18 21:16 ` David Ahern

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).