netdev - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 1 Feb 2022 22:59:14 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Quentin Monnet <quentin@...valent.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 3/3] bpftool: Update versioning scheme

On Mon, Jan 31, 2022 at 1:11 PM Quentin Monnet <quentin@...valent.com> wrote:
>
> 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
> +

It's going to be a PITA to not forget to update this :( As discussed,
I'm fine with this, but I also recalled the versioning approach that
libbpf-sys library is using (see [0]). Maybe we could steal some of
those ideas. As in, base bpftool version on libbpf (with major version
+ 6 as you do here), but also have "-1", "-2", etc suffixes for
bpftool releases for when libbpf version didn't change. Don't know,
just throwing out the idea for your consideration.

  [0] https://github.com/libbpf/libbpf-sys#versioning


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