Re: [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf

Daniel Borkmann [off-list ref] writes:

On 8/22/19 12:43 PM, Toke Høiland-Jørgensen wrote:

quoted

Daniel Borkmann [off-list ref] writes:

quoted

On 8/20/19 1:47 PM, Toke Høiland-Jørgensen wrote:

quoted

This adds a configure check for libbpf and renames functions to allow
lib/bpf.c to be compiled with it present. This makes it possible to
port functionality piecemeal to use libbpf.

Signed-off-by: Toke Høiland-Jørgensen <redacted>
---
   configure          | 16 ++++++++++++++++
   include/bpf_util.h |  6 +++---
   ip/ipvrf.c         |  4 ++--
   lib/bpf.c          | 33 +++++++++++++++++++--------------
   4 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index 45fcffb6..5a89ee9f 100755
--- a/configure
+++ b/configure

@@ -238,6 +238,19 @@ check_elf()
       fi
   }
   
+check_libbpf()
+{
+    if ${PKG_CONFIG} libbpf --exists; then
+	echo "HAVE_LIBBPF:=y" >>$CONFIG
+	echo "yes"
+
+	echo 'CFLAGS += -DHAVE_LIBBPF' `${PKG_CONFIG} libbpf --cflags` >> $CONFIG
+	echo 'LDLIBS += ' `${PKG_CONFIG} libbpf --libs` >>$CONFIG
+    else
+	echo "no"
+    fi
+}
+
   check_selinux()

More of an implementation detail at this point in time, but want to
make sure this doesn't get missed along the way: as discussed at
bpfconf [0] best for iproute2 to handle libbpf support would be the
same way of integration as pahole does, that is, to integrate it via
submodule [1] to allow kernel and libbpf features to be in sync with
iproute2 releases and therefore easily consume extensions we're adding
to libbpf to aide iproute2 integration.

I can sorta see the point wrt keeping in sync with kernel features. But
how will this work with distros that package libbpf as a regular
library? Have you guys given up on regular library symbol versioning for
libbpf?

Not at all, and I hope you know that. ;-)

Good! Didn't really expect you had, just checking ;)

The reason I added lib/bpf.c integration into iproute2 directly back
then was exactly such that users can start consuming BPF for tc and
XDP via iproute2 /everywhere/ with only a simple libelf dependency
which is also available on all distros since pretty much forever. If
it was an external library, we could have waited till hell freezes
over and initial distro adoption would have pretty much taken forever:
to pick one random example here wrt the pace of some downstream
distros [0]. The main rationale is pretty much the same as with added
kernel features that land complementary iproute2 patches for that
kernel release and as libbpf is developed alongside it is reasonable
to guarantee user expectations that iproute2 released for kernel
version x can make use of BPF features added to kernel x with same
loader support from x.

Well, for iproute2 I would expect this to be solved by version
dependencies. I.e. iproute2 version X would depend on libbpf version Y+
(like, I dunno, the version of libbpf included in the same kernel source
tree as the kernel version iproute2 is targeting? :)).

If we vendor libbpf into every project using it, we'll end up with
dozens of different versions statically linked into each binary, kinda
defeating the purpose of having it as a shared library in the first
place...

-Toke