netdev - Re: Bpftool mirror now available

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]

Message-ID: <15f76929-a953-e540-014f-170dd95dddb1@isovalent.com>
Date:   Mon, 24 Jan 2022 10:37:30 +0000
From:   Quentin Monnet <quentin@...valent.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Dave Thaler <dthaler@...rosoft.com>
Subject: Re: Bpftool mirror now available

2022-01-20 11:07 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@...il.com>
> On Thu, Jan 20, 2022 at 4:35 AM Quentin Monnet <quentin@...valent.com> wrote:
>>
>> 2022-01-19 22:25 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@...il.com>
>>> On Wed, Jan 19, 2022 at 6:47 AM Quentin Monnet <quentin@...valent.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.

Right, let's not tie it to libbpf either, having an independent
versioning scheme is probably the best solution indeed. I'll send a
patchset shortly to update the version and also print the one from libbpf.

Thanks,
Quentin