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 14:13:49 -0700
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Luca Boccassi <bluca@...ian.org>, netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v2] tools/bpf: generate pkg-config file for
 libbpf

On 03/20, Daniel Borkmann wrote:
> On 03/20/2019 09:44 PM, Stanislav Fomichev wrote:
> > 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.
> 
> Current workflow regarding libbpf versioning is that version number
> increase is synced with kernel release. Meaning, new development cycle
> we bump the version when we e.g. add entries into libbpf.map file for
> new api functions.
So it will have its own version, not matching the kernel? I thought we
would keep it 0.0.X until we figure things out and then just follow the
kernel. (I'm fine either way, just wondering).

It's still 0.0.1 in Linus's tree, bpf and in bpf-next btw, even though we
already have LIBBPF_0.0.2 in the libbpf.map file :-)