netdev - [PATCH bpf-next 3/3] bpftool: Update versioning scheme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 31 Jan 2022 21:11:36 +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 3/3] bpftool: Update versioning scheme

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.

It would make more sense to align bpftool's number on libbpf, maybe.
When versioning was introduced in bpftool, libbpf was in its initial
phase at v0.0.1. Now it moves faster, with regular version bumps. But
there are two issues if we want to pick the same numbers. First, that
would mean going backward on the numbering, and will be a huge pain for
every script trying to determine which bpftool binary is the most
recent (not to mention some possible overlap of the numbers in a distant
future). Then, bpftool could get new features or bug fixes between two
versions libbpf, so maybe we should not completely tie its versions to
libbpf, either.

Therefore, this commit introduces an independent versioning scheme for
bpftool. The new version is v6.0.0, with its major number incremented
over the current 5.16.* returned from the kernel's Makefile. The plan is
to update this new number from time to time when bpftool gets new
features or new bug fixes. These updates could possibly lead to new
releases being tagged on the recently created out-of-tree mirror, at
https://github.com/libbpf/bpftool.

Version number is moved higher in the Makefile, to make it more visible.

Suggested-by: Andrii Nakryiko <andrii@...nel.org>
Signed-off-by: Quentin Monnet <quentin@...valent.com>
---
 tools/bpf/bpftool/Makefile | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index bd5a8cafac49..b7dbdea112d3 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 include ../../scripts/Makefile.include

+BPFTOOL_VERSION := 6.0.0
+
 ifeq ($(srctree),)
 srctree := $(patsubst %/,%,$(dir $(CURDIR)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
@@ -39,9 +41,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_VERSION := $(shell make -r --no-print-directory -sC $(BPF_DIR) libbpfversion)

 $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR):
-- 
2.32.0