Date:   Wed, 2 Feb 2022 18:59:05 +0000
From:   Quentin Monnet <quentin@...valent.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.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

2022-02-01 22:59 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@...il.com>
> 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

I've been somewhat torn between having a separate versioning scheme and
getting as much flexibility as we want, and aligning on libbpf and
having “automatic” version updates. My reasoning is the following.

If aligning on libbpf:

- We may want bpftool releases in-between two libbpf versions. Using
pre-release numbers for tagging them is a good idea, although I don't
know if something marked as a pre-release will look “official” enough
(users may not pick it, thinking it's a beta release?). On the other
hand, having bpftool with version numbers that look “official” haven'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 as you
say, it's gonna be painful to update the numbers. Developers will miss
it most of the time, and I'm not even exactly sure myself of when to tag
a new minor release. I suppose it would be a bit like for docs and
completion, with occasional “catch-up” patches to update the version
number - not great.

Based on all the above, I think your suggestion is good, and I'll switch
back to aligning on libbpf's version. It may not be perfect, but 1) it's
certainly an improvement over the current scheme, 2) the issues raised
above are minor at the moment, and 3) we can still move to an
independent scheme in the future if we realise we need it. Sounds more
important to save on the maintenance burden at the moment. I'll send a
new version shortly.

Thanks,
Quentin

Powered by blists - more mailing lists