Message-Id: <20220208120648.49169-4-quentin@isovalent.com>
Date:   Tue,  8 Feb 2022 12:06:48 +0000
From:   Quentin Monnet <quentin@...valent.com>
To:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        Quentin Monnet <quentin@...valent.com>
Subject: [PATCH bpf-next v2 3/3] bpftool: Update versioning scheme, align on libbpf's version number

Since the notion of versions was introduced for bpftool, it has been
following the version number of the kernel (using the version number
corresponding to the tree in which bpftool's sources are located). The
rationale was that bpftool's features are loosely tied to BPF features
in the kernel, and that we could defer versioning to the kernel
repository itself.

But this versioning scheme is confusing today, because a bpftool binary
should be able to work with both older and newer kernels, even if some
of its recent features won't be available on older systems. Furthermore,
if bpftool is ported to other systems in the future, keeping a
Linux-based version number is not a good option.

Looking at other options, we could either have a totally independent
scheme for bpftool, or we could align it on libbpf's version number
(with an offset on the major version number, to avoid going backwards).
The latter comes with a few drawbacks:

- We may want bpftool releases in-between two libbpf versions. We can
  always append pre-release numbers to distinguish versions, although
  those won't look as "official" as something with a proper release
  number. But at the same time, having bpftool with version numbers that
  look "official" hasn't really been an issue so far.

- If no new feature lands in bpftool for some time, we may move from
  e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
  versions which are in fact the same.

- Following libbpf's versioning scheme sounds better than kernel's, but
  ultimately it doesn't make too much sense either, because even though
  bpftool uses the lib a lot, its behaviour is not that much conditioned
  by the internal evolution of the library (or by new APIs that it may
  not use).

Having an independent versioning scheme solves the above, but at the
cost of heavier maintenance. Developers will likely forget to increase
the numbers when adding features or bug fixes, and we would take the
risk of having to send occasional "catch-up" patches just to update the
version number.

Based on these considerations, this patch aligns bpftool's version
number on libbpf's. This is not a perfect solution, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are all minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it.

Given that libbpf is currently at version 0.7.0, and bpftool, before
this patch, was at 5.16, we use an offset of 6 for the major version,
bumping bpftool to 6.7.0.

It remains possible to manually override the version number by setting
BPFTOOL_VERSION when calling make.

Signed-off-by: Quentin Monnet <quentin@...valent.com>
---
Contrarily to the previous discussion and to what the first patch of the
set does, I chose not to use the libbpf_version_string() API from libbpf
to compute the version for bpftool. There were three reasons for that:

- I don't feel comfortable having bpftool's version number computed at
  runtime. Somehow it really feels like we should now it when we compile
  it. We link statically against libbpf today, but if we were to support
  dynamic linking in the future we may forget to update and would have
  bpftool's version changing based on the libbpf version installed
  beside it, which does not make sense.

- We cannot get the patch version for libbpf, the current API only
  returns the major and minor version numbers (we could fix it, although
  I'm not sure if desirable to expose the patch number).

- I found it less elegant to compute the version strings in the code,
  which meant malloc() and error handling just for printing a version
  number, and having a separate case for when $(BPFTOOL_VERSION) is
  defined, whereas passing a macro from the Makefile makes things
  straightforwards.
---
 tools/bpf/bpftool/Makefile | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 83369f55df61..8dd30abff3d9 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -7,14 +7,21 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
 endif
 
+BPF_DIR = $(srctree)/tools/lib/bpf
+
+# bpftool's version is libbpf's with a fixed offset for the major version.
+# This is because bpftool's version was higher than libbpf's when we adopted
+# this scheme.
+BPFTOOL_MAJOR_OFFSET := 6
+LIBBPF_VERSION := $(shell make -r --no-print-directory -sC $(BPF_DIR) libbpfversion)
+BPFTOOL_VERSION ?= $(shell lv="$(LIBBPF_VERSION)"; echo "$$((${lv%%.*} + $(BPFTOOL_MAJOR_OFFSET))).$${lv#*.}")
+
 ifeq ($(V),1)
   Q =
 else
   Q = @
 endif
 
-BPF_DIR = $(srctree)/tools/lib/bpf
-
 ifneq ($(OUTPUT),)
   _OUTPUT := $(OUTPUT)
 else
@@ -39,10 +46,6 @@ LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a
 LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h)
 LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h)
 
-ifeq ($(BPFTOOL_VERSION),)
-BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion)
-endif
-
 $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR):
 	$(QUIET_MKDIR)mkdir -p $@
 
-- 
2.32.0

Powered by blists - more mailing lists