netdev - Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <730c2c2a-d743-cedf-265e-a22e706f2882@gmail.com>
Date:   Wed, 4 Nov 2020 19:39:19 -0700
From:   David Ahern <dsahern@...il.com>
To:     Jiri Benc <jbenc@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Hangbin Liu <haliu@...hat.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Toke Høiland-Jørgensen 
        <toke@...hat.com>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 11/4/20 2:28 AM, Jiri Benc wrote:
> On Tue, 3 Nov 2020 18:45:59 -0800, Alexei Starovoitov wrote:
>> libbpf is the only library I know that is backward and forward compatible.
> 
> This is great to hear. It means there will be no problem with iproute2
> using the system libbpf. As libbpf is both backward and forward
> compatible, iproute2 will just work with whatever version it is used
> with.

That is how I read that as well. The bpf team is making sure libbpf is a
stable, robust front-end to kernel APIs. That stability is what controls
the user experience. With the due diligence in testing, packages using
libbpf can have confidence that using an libbpf API is not going to
change release over release regardless of kernel version installed
(i.e., as kernel versions go newer from an OS start point - typical
scenario for a distribution).


> 
> The only problem would be if a particular function changed its
> semantics while retaining ABI. But since libbpf is backward and forward
> compatible, this should not happen.

exactly.

Then, If libbpf needs to change something that affects users, it bumps
the soname version.