netdev - Re: [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation

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, 27 Nov 2018 12:36:03 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrey Ignatov <rdna@...com>
Cc:     netdev@...r.kernel.org, ast@...nel.org, yhs@...com, kafai@...com,
        kernel-team@...com
Subject: Re: [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation

On 11/27/2018 04:06 AM, Alexei Starovoitov wrote:
> On Fri, Nov 23, 2018 at 04:44:31PM -0800, Andrey Ignatov wrote:
>> This patch set adds ABI versioning and documentation to libbpf.
>>
>> Patch 1 renames btf_get_from_id to btf__get_from_id to follow naming
>> convention.
>> Patch 2 adds version script and has more details on ABI versioning.
>> Patch 3 adds simple check that all global symbols are versioned.
>> Patch 4 documents a few aspects of libbpf API and ABI in dev process.
>>
>> v1->v2:
>> * add patch from Martin KaFai Lau <kafai@...com> to rename btf_get_from_id;
>> * add documentation for libbpf API and ABI.
> 
> All looks great to me.
> Thank you for adding the doc.
> Applied to bpf-next.
> 
> We need to discuss the release model and version bumps.
> For example I don't think it's necessary to bump the version
> and update libbpf.map every time the new function is added.
> I mean we can synchronize release of libbpf with the release of the kernel
> or release it every N weeks.

+1, synchronizing with release of the kernel seems a natural fit
given it's part of the kernel tree. Every N weeks might not even
work since changes are not in Linus' tree at that point, I think
this would probably just lead to confusion.

> So if we add new api functions during this release we can simply
> add them to libbpf.map while keeping the version as 0.0.1
> 
> I'd also consider the first 0.0.1 release to be experimental
> while we're figuring out the right process.
> For the next kernel/libbpf release I propose to bump it to 1.0.0
> 
> Another idea is to version it just like kernel and make libbpf version
> always equal kernel version.
> But I think that would be an overkill. libbpf isn't tightly coupled to
> the kernel. Like we just merged the patch (prog_name/map_name probing
> that allows new libbpf to work with older kernel.

Right, though we might end up bumping version each kernel release
anyway. This would allow for more automation on that part if we
could simply say that version looks like libbpf.so.4.20 or
libbpf.so.4.21, etc, without us forgetting to send an extra patch
every release just to bump version. Whether it's version -0.0.1,
-1.0.0, -4.20 or say -2018.11.27 is probably mostly matter of
preference but for the former two we would have to additionally
establish some convention / process on when to bump which part
of the three version component. I'd rather prefer if we could
have kernel-like convention where a bump in major version is "just"
yet another release but has no other special meaning attached to
it in which case we could just adapt the same numbering scheme.

Thanks,
Daniel