From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>
Cc: bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Dave Thaler <dthaler@microsoft.com>
Subject: Re: Bpftool mirror now available
Date: Thu, 20 Jan 2022 11:07:58 -0800 [thread overview]
Message-ID: <CAEf4BzaiUbAT4hBKTVYadGdygccA3c6jgPsu8VW9sLo+4Ofsvw@mail.gmail.com> (raw)
In-Reply-To: <ac3f95ed-bead-e8ea-b477-edcbd809452c@isovalent.com>
On Thu, Jan 20, 2022 at 4:35 AM Quentin Monnet <quentin@isovalent.com> wrote:
>
> 2022-01-19 22:25 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > On Wed, Jan 19, 2022 at 6:47 AM Quentin Monnet <quentin@isovalent.com> wrote:
>
> [...]
>
> >> 2. Because it is easier to compile and ship, this mirror should
> >> hopefully simplify bpftool packaging for distributions.
> >
> > Right, I hope disto packagers will be quick to adopt the new mirror
> > repo for packaging bpftool. Let's figure out bpftool versioning schema
> > as a next step. Given bpftool heavily relies on libbpf and isn't
> > really coupled to kernel versions, it makes sense for bpftool to
> > reflect libbpf version rather than kernel's. WDYT?
>
> Personally, I don't mind finding another scheme, as long as we keep it
> consistent between the reference sources in the kernel repo and the mirror.
>
> I also agree that it would make sense to align it to libbpf, but that
> would mean going backward on the numbers (current version is 5.16.0,
> libbpf's is 0.7.0) and this will mess up with every script trying to
> compare versions. We could maybe add a prefix to indicate that the
> scheme has changed ('l_0.7.0), but similarly, it would break a good
> number of tools that expect semantic versioning, I don't think this is
> any better.
>
> The other alternative I see would be to pick a different major version
> number and arbitrarily declare that bpftool's version is aligned on
> libbpf's, but with a difference of 6 for the version number. So we would
> start at 6.7.0 and reach 7.0.0 when libbpf 1.0.0 is released. This is
> not ideal, but we would keep some consistency, and we can always add the
> version of libbpf used for the build to "bpftool version"'s output. How
> would you feel about it? Did you have something else in mind?
Yeah, this off-by-6 major version difference seems ok-ish to me, I
don't mind that. Another alternative is to have a completely
independent versioning (and report used libbpf version in bpftool
--version output separately). But I think divorcing it from kernel
version is a must, too much confusion.
>
> Quentin
next prev parent reply other threads:[~2022-01-20 19:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-19 14:47 Bpftool mirror now available Quentin Monnet
2022-01-20 6:25 ` Andrii Nakryiko
2022-01-20 12:35 ` Quentin Monnet
2022-01-20 19:07 ` Andrii Nakryiko [this message]
2022-01-24 10:37 ` Quentin Monnet
2022-01-20 14:19 ` Dave Thaler
2022-01-24 12:13 ` Quentin Monnet
2022-01-25 3:39 ` Dave Thaler
2022-01-25 21:42 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEf4BzaiUbAT4hBKTVYadGdygccA3c6jgPsu8VW9sLo+4Ofsvw@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dthaler@microsoft.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin@isovalent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).