netdev - Re: [PATCH bpf-next v2] tools/bpf: generate pkg-config file for 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]

Date:   Wed, 20 Mar 2019 13:44:38 -0700
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     Luca Boccassi <bluca@...ian.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v2] tools/bpf: generate pkg-config file for
 libbpf

On 03/20, Luca Boccassi wrote:
> On Wed, 2019-03-20 at 10:21 -0700, Stanislav Fomichev wrote:
> > On 03/20, Luca Boccassi wrote:
> > > On Wed, 2019-03-20 at 13:22 +0000, Luca Boccassi wrote:
> > > > On Tue, 2019-03-19 at 16:17 -0700, Stanislav Fomichev wrote:
> > > > > On 03/19, Luca Boccassi wrote:
> > > > > > Generate a libbpf.pc file at build time so that users can
> > > > > > rely
> > > > > > on pkg-config to find the library, its CFLAGS and LDFLAGS.
> > > > > > 
> > > > > > Signed-off-by: Luca Boccassi <bluca@...ian.org>
> > > > > > ---
> > > > > > v2: use QUIET_GEN instead of QUIET_LINK to generate pc file,
> > > > > >     save kernel version in its own variable instead of
> > > > > > calling
> > > > > >     make inline
> > > > > > 
> > > > > >  tools/lib/bpf/.gitignore         |  1 +
> > > > > >  tools/lib/bpf/Makefile           | 19 ++++++++++++++++---
> > > > > >  tools/lib/bpf/libbpf.pc.template | 11 +++++++++++
> > > > > >  3 files changed, 28 insertions(+), 3 deletions(-)
> > > > > >  create mode 100644 tools/lib/bpf/libbpf.pc.template
> > > > > > 
> > > > > > diff --git a/tools/lib/bpf/.gitignore
> > > > > > b/tools/lib/bpf/.gitignore
> > > > > > index 4db74758c674..7d9e182a1f51 100644
> > > > > > --- a/tools/lib/bpf/.gitignore
> > > > > > +++ b/tools/lib/bpf/.gitignore
> > > > > > @@ -1,3 +1,4 @@
> > > > > >  libbpf_version.h
> > > > > > +libbpf.pc
> > > > > >  FEATURE-DUMP.libbpf
> > > > > >  test_libbpf
> > > > > > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> > > > > > index a05c43468bd0..1df3ebfb3118 100644
> > > > > > --- a/tools/lib/bpf/Makefile
> > > > > > +++ b/tools/lib/bpf/Makefile
> > > > > > @@ -80,6 +80,7 @@ libdir_SQ = $(subst ','\'',$(libdir))
> > > > > >  libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
> > > > > >  
> > > > > >  LIB_FILE = libbpf.a libbpf.so
> > > > > > +PC_FILE = libbpf.pc
> > > > > >  
> > > > > >  VERSION		= $(BPF_VERSION)
> > > > > >  PATCHLEVEL	= $(BPF_PATCHLEVEL)
> > > > > > @@ -89,6 +90,7 @@ OBJ		= $@
> > > > > >  N		=
> > > > > >  
> > > > > >  LIBBPF_VERSION =
> > > > > > $(BPF_VERSION).$(BPF_PATCHLEVEL).$(BPF_EXTRAVERSION)
> > > > > > +KERNEL_VERSION = $(shell make --no-print-directory -sC
> > > > > > ../../..
> > > > > > kernelversion)
> > > > > Oh, we do already have LIBBPF_VERSION, why not use that? This
> > > > > way
> > > > > you don't need to do anything for out-of-tree libbpf from
> > > > > github.
> > > > > 
> > > > > I don't remember what was the strategy regarding libbpf
> > > > > versioning,
> > > > > but
> > > > > that 0.0.1 should be changed to something sensible (be set to
> > > > > the
> > > > > kernel
> > > > > version upon release?)
> > > > 
> > > > [re-sending as reply via phone added html and the list daemon
> > > > said
> > > > no-
> > > > no]
> > > > 
> > > > That looks like the ABI version though, rather than the source
> > > > version?
> > > > The source version is more appropriate for the PC file
> > > 
> > > That said, the versioning looks looks like it could use some love
> > > and
> > > it's not really a factor that should gate a pkg-config file and
> > > could
> > > be done separately if required, so in v3 I've removed
> > > KERNEL_VERSION
> > > and used LIBBPF_VERSION as you suggested.
> > Agree :-) There was some conversation recently about incrementing it
> > per
> > kernel release vs real api change. I don't remember what the outcome
> > was exactly.
> 
> I see, thanks. Anything else you'd like me to change?
No, everything looks good to me, wait for the reply from the bpf
maintainers.

> -- 
> Kind regards,
> Luca Boccassi