netdev - Re: [PATCH bpf-next 03/15] libbpf: move non-public APIs from libbpf.h to libbpf

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: <CAEf4BzbYvNJ0VV2jHLVK3jwk+_GvVhSWk_-YM2Twu5XkZduZVQ@mail.gmail.com>
Date:   Tue, 10 Dec 2019 09:04:58 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 03/15] libbpf: move non-public APIs from libbpf.h
 to libbpf_internal.h

On Mon, Dec 9, 2019 at 5:33 PM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> On Mon, 9 Dec 2019 17:14:26 -0800, Andrii Nakryiko wrote:
> > Few libbpf APIs are not public but currently exposed through libbpf.h to be
> > used by bpftool. Move them to libbpf_internal.h, where intent of being
> > non-stable and non-public is much more obvious.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@...com>
> > ---
> >  tools/bpf/bpftool/net.c         |  1 +
> >  tools/lib/bpf/libbpf.h          | 17 -----------------
> >  tools/lib/bpf/libbpf_internal.h | 17 +++++++++++++++++
> >  3 files changed, 18 insertions(+), 17 deletions(-)
> >
> > diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> > index 4f52d3151616..d93bee298e54 100644
> > --- a/tools/bpf/bpftool/net.c
> > +++ b/tools/bpf/bpftool/net.c
> > @@ -18,6 +18,7 @@
> >
> >  #include <bpf.h>
> >  #include <nlattr.h>
> > +#include "libbpf_internal.h"
> >  #include "main.h"
> >  #include "netlink_dumper.h"
>
> I thought this idea was unpopular when proposed?

There was a recent discussion about the need for unstable APIs to be
exposed to bpftool and we concluded that libbpf_internal.h is the most
appropriate place to do this.