Message ID | 20201028132529.3763875-1-haliu@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | iproute2: add libbpf support | expand |
On 10/28/20 7:25 AM, Hangbin Liu wrote: > This series converts iproute2 to use libbpf for loading and attaching > BPF programs when it is available. This means that iproute2 will > correctly process BTF information and support the new-style BTF-defined > maps, while keeping compatibility with the old internal map definition > syntax. > > This is achieved by checking for libbpf at './configure' time, and using > it if available. By default the system libbpf will be used, but static > linking against a custom libbpf version can be achieved by passing > LIBBPF_DIR to configure. FORCE_LIBBPF can be set to force configure to > abort if no suitable libbpf is found (useful for automatic packaging > that wants to enforce the dependency). > > The old iproute2 bpf code is kept and will be used if no suitable libbpf > is available. When using libbpf, wrapper code ensures that iproute2 will > still understand the old map definition format, including populating > map-in-map and tail call maps before load. > > The examples in bpf/examples are kept, and a separate set of examples > are added with BTF-based map definitions for those examples where this > is possible (libbpf doesn't currently support declaratively populating > tail call maps). > > At last, Thanks a lot for Toke's help on this patch set. > > > v2: > a) Remove self defined IS_ERR_OR_NULL and use libbpf_get_error() instead. > b) Add ipvrf with libbpf support. > > fails to compile on Ubuntu 20.10: root@u2010-sfo3:~/iproute2.git# ./configure TC schedulers ATM yes IPT using xtables IPSET yes iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables libc has setns: yes SELinux support: yes libbpf support: yes ELF support: yes libmnl support: yes Berkeley DB: no need for strlcpy: yes libcap support: yes root@u2010-sfo3:~/iproute2.git# make clean root@u2010-sfo3:~/iproute2.git# make -j 4 ... /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': bpf_libbpf.c:(.text+0x3cb): undefined reference to `bpf_program__section_name' /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to `bpf_program__section_name' /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to `bpf_program__section_name' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:27: ip] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:64: all] Error 2
On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > fails to compile on Ubuntu 20.10: > > root@u2010-sfo3:~/iproute2.git# ./configure > TC schedulers > ATM yes > IPT using xtables > IPSET yes > > iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > libc has setns: yes > SELinux support: yes > libbpf support: yes > ELF support: yes > libmnl support: yes > Berkeley DB: no > need for strlcpy: yes > libcap support: yes > > root@u2010-sfo3:~/iproute2.git# make clean > > root@u2010-sfo3:~/iproute2.git# make -j 4 > ... > /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > bpf_libbpf.c:(.text+0x3cb): undefined reference to > `bpf_program__section_name' > /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > `bpf_program__section_name' > /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > `bpf_program__section_name' > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:27: ip] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [Makefile:64: all] Error 2 You need to update libbpf to latest version. But this also remind me that I need to add bpf_program__section_name() to configure checking. I will see if I missed other functions' checking. Thanks Hangbin
On 10/28/20 8:06 PM, Hangbin Liu wrote: > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: >> fails to compile on Ubuntu 20.10: >> >> root@u2010-sfo3:~/iproute2.git# ./configure >> TC schedulers >> ATM yes >> IPT using xtables >> IPSET yes >> >> iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables >> libc has setns: yes >> SELinux support: yes >> libbpf support: yes >> ELF support: yes >> libmnl support: yes >> Berkeley DB: no >> need for strlcpy: yes >> libcap support: yes >> >> root@u2010-sfo3:~/iproute2.git# make clean >> >> root@u2010-sfo3:~/iproute2.git# make -j 4 >> ... >> /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': >> bpf_libbpf.c:(.text+0x3cb): undefined reference to >> `bpf_program__section_name' >> /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to >> `bpf_program__section_name' >> /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to >> `bpf_program__section_name' >> collect2: error: ld returned 1 exit status >> make[1]: *** [Makefile:27: ip] Error 1 >> make[1]: *** Waiting for unfinished jobs.... >> make: *** [Makefile:64: all] Error 2 > > You need to update libbpf to latest version. nope. you need to be able to handle this. Ubuntu 20.10 was just released, and it has a version of libbpf. If you are going to integrate libbpf into other packages like iproute2, it needs to just work with that version. > > But this also remind me that I need to add bpf_program__section_name() to > configure checking. I will see if I missed other functions' checking. This is going to be an on-going problem. iproute2 should work with whatever version of libbpf is installed on that system.
On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > fails to compile on Ubuntu 20.10: > > > > root@u2010-sfo3:~/iproute2.git# ./configure > > TC schedulers > > ATM yes > > IPT using xtables > > IPSET yes > > > > iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > > libc has setns: yes > > SELinux support: yes > > libbpf support: yes > > ELF support: yes > > libmnl support: yes > > Berkeley DB: no > > need for strlcpy: yes > > libcap support: yes > > > > root@u2010-sfo3:~/iproute2.git# make clean > > > > root@u2010-sfo3:~/iproute2.git# make -j 4 > > ... > > /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > > bpf_libbpf.c:(.text+0x3cb): undefined reference to > > `bpf_program__section_name' > > /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > > `bpf_program__section_name' > > /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > > `bpf_program__section_name' > > collect2: error: ld returned 1 exit status > > make[1]: *** [Makefile:27: ip] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [Makefile:64: all] Error 2 > > You need to update libbpf to latest version. Why not using libbpf from submodule? > > But this also remind me that I need to add bpf_program__section_name() to > configure checking. I will see if I missed other functions' checking. > > Thanks > Hangbin >
On Thu, 29 Oct 2020 10:06:37 +0800 Hangbin Liu <haliu@redhat.com> wrote: > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > fails to compile on Ubuntu 20.10: > > > > root@u2010-sfo3:~/iproute2.git# ./configure > > TC schedulers > > ATM yes > > IPT using xtables > > IPSET yes > > > > iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > > libc has setns: yes > > SELinux support: yes > > libbpf support: yes > > ELF support: yes > > libmnl support: yes > > Berkeley DB: no > > need for strlcpy: yes > > libcap support: yes > > > > root@u2010-sfo3:~/iproute2.git# make clean > > > > root@u2010-sfo3:~/iproute2.git# make -j 4 > > ... > > /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > > bpf_libbpf.c:(.text+0x3cb): undefined reference to > > `bpf_program__section_name' > > /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > > `bpf_program__section_name' > > /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > > `bpf_program__section_name' > > collect2: error: ld returned 1 exit status > > make[1]: *** [Makefile:27: ip] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [Makefile:64: all] Error 2 > > You need to update libbpf to latest version. > > But this also remind me that I need to add bpf_program__section_name() to > configure checking. I will see if I missed other functions' checking. > > Thanks > Hangbin > Then configure needs to check for this or every distro is going to get real mad...
On 10/28/20 8:27 PM, Andrii Nakryiko wrote: > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: >> >> On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: >>> fails to compile on Ubuntu 20.10: >>> >>> root@u2010-sfo3:~/iproute2.git# ./configure >>> TC schedulers >>> ATM yes >>> IPT using xtables >>> IPSET yes >>> >>> iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables >>> libc has setns: yes >>> SELinux support: yes >>> libbpf support: yes >>> ELF support: yes >>> libmnl support: yes >>> Berkeley DB: no >>> need for strlcpy: yes >>> libcap support: yes >>> >>> root@u2010-sfo3:~/iproute2.git# make clean >>> >>> root@u2010-sfo3:~/iproute2.git# make -j 4 >>> ... >>> /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': >>> bpf_libbpf.c:(.text+0x3cb): undefined reference to >>> `bpf_program__section_name' >>> /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to >>> `bpf_program__section_name' >>> /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to >>> `bpf_program__section_name' >>> collect2: error: ld returned 1 exit status >>> make[1]: *** [Makefile:27: ip] Error 1 >>> make[1]: *** Waiting for unfinished jobs.... >>> make: *** [Makefile:64: all] Error 2 >> >> You need to update libbpf to latest version. > > Why not using libbpf from submodule? > no. iproute2 does not bring in libmnl, libc, ... a submodules. libbpf is not special. OS versions provide it and it needs to co-exist with packages.
On Wed, 28 Oct 2020 19:27:20 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > > fails to compile on Ubuntu 20.10: > > > > > > root@u2010-sfo3:~/iproute2.git# ./configure > > > TC schedulers > > > ATM yes > > > IPT using xtables > > > IPSET yes > > > > > > iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > > > libc has setns: yes > > > SELinux support: yes > > > libbpf support: yes > > > ELF support: yes > > > libmnl support: yes > > > Berkeley DB: no > > > need for strlcpy: yes > > > libcap support: yes > > > > > > root@u2010-sfo3:~/iproute2.git# make clean > > > > > > root@u2010-sfo3:~/iproute2.git# make -j 4 > > > ... > > > /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > > > bpf_libbpf.c:(.text+0x3cb): undefined reference to > > > `bpf_program__section_name' > > > /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > > > `bpf_program__section_name' > > > /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > > > `bpf_program__section_name' > > > collect2: error: ld returned 1 exit status > > > make[1]: *** [Makefile:27: ip] Error 1 > > > make[1]: *** Waiting for unfinished jobs.... > > > make: *** [Makefile:64: all] Error 2 > > > > You need to update libbpf to latest version. > > Why not using libbpf from submodule? Because it makes it harder for people downloading tarballs and distributions. Iproute2 has worked well by being standalone. Want to merge libbpf into iproute2??
On Wed, Oct 28, 2020 at 08:20:55PM -0600, David Ahern wrote: > >> root@u2010-sfo3:~/iproute2.git# make -j 4 > >> ... > >> /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > >> bpf_libbpf.c:(.text+0x3cb): undefined reference to > >> `bpf_program__section_name' > >> /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > >> `bpf_program__section_name' > >> /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > >> `bpf_program__section_name' > >> collect2: error: ld returned 1 exit status > >> make[1]: *** [Makefile:27: ip] Error 1 > >> make[1]: *** Waiting for unfinished jobs.... > >> make: *** [Makefile:64: all] Error 2 > > > > You need to update libbpf to latest version. > > nope. you need to be able to handle this. Ubuntu 20.10 was just > released, and it has a version of libbpf. If you are going to integrate > libbpf into other packages like iproute2, it needs to just work with > that version. OK, I can replace bpf_program__section_name by bpf_program__title(). > > > > > But this also remind me that I need to add bpf_program__section_name() to > > configure checking. I will see if I missed other functions' checking. > > This is going to be an on-going problem. iproute2 should work with > whatever version of libbpf is installed on that system. I will make it works on Ubuntu 20.10, but with whatever version of libbpf? That looks hard, especially with old libbpf. Thanks Hangbin
On Wed, Oct 28, 2020 at 7:33 PM David Ahern <dsahern@gmail.com> wrote: > > On 10/28/20 8:27 PM, Andrii Nakryiko wrote: > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > >> > >> On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > >>> fails to compile on Ubuntu 20.10: > >>> > >>> root@u2010-sfo3:~/iproute2.git# ./configure > >>> TC schedulers > >>> ATM yes > >>> IPT using xtables > >>> IPSET yes > >>> > >>> iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > >>> libc has setns: yes > >>> SELinux support: yes > >>> libbpf support: yes > >>> ELF support: yes > >>> libmnl support: yes > >>> Berkeley DB: no > >>> need for strlcpy: yes > >>> libcap support: yes > >>> > >>> root@u2010-sfo3:~/iproute2.git# make clean > >>> > >>> root@u2010-sfo3:~/iproute2.git# make -j 4 > >>> ... > >>> /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > >>> bpf_libbpf.c:(.text+0x3cb): undefined reference to > >>> `bpf_program__section_name' > >>> /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > >>> `bpf_program__section_name' > >>> /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > >>> `bpf_program__section_name' > >>> collect2: error: ld returned 1 exit status > >>> make[1]: *** [Makefile:27: ip] Error 1 > >>> make[1]: *** Waiting for unfinished jobs.... > >>> make: *** [Makefile:64: all] Error 2 > >> > >> You need to update libbpf to latest version. > > > > Why not using libbpf from submodule? > > > > no. iproute2 does not bring in libmnl, libc, ... a submodules. libbpf is > not special. OS versions provide it and it needs to co-exist with packages. Not saying libbpf is special, but libbpf is a fast moving target right now, so it's pragmatic to have it as submodule, because if you'd like to use some latest functionality, you won't have to add all the conditional compilation shenanigans to detect every single new API you'd like to use from libbpf. And libbpf is pretty small to not worry about saving memory through a shared library. But it's up to you guys, of course.
On Wed, Oct 28, 2020 at 7:34 PM Stephen Hemminger <stephen@networkplumber.org> wrote: > > On Wed, 28 Oct 2020 19:27:20 -0700 > Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > > > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > > > fails to compile on Ubuntu 20.10: > > > > > > > > root@u2010-sfo3:~/iproute2.git# ./configure > > > > TC schedulers > > > > ATM yes > > > > IPT using xtables > > > > IPSET yes > > > > > > > > iptables modules directory: /usr/lib/x86_64-linux-gnu/xtables > > > > libc has setns: yes > > > > SELinux support: yes > > > > libbpf support: yes > > > > ELF support: yes > > > > libmnl support: yes > > > > Berkeley DB: no > > > > need for strlcpy: yes > > > > libcap support: yes > > > > > > > > root@u2010-sfo3:~/iproute2.git# make clean > > > > > > > > root@u2010-sfo3:~/iproute2.git# make -j 4 > > > > ... > > > > /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': > > > > bpf_libbpf.c:(.text+0x3cb): undefined reference to > > > > `bpf_program__section_name' > > > > /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to > > > > `bpf_program__section_name' > > > > /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to > > > > `bpf_program__section_name' > > > > collect2: error: ld returned 1 exit status > > > > make[1]: *** [Makefile:27: ip] Error 1 > > > > make[1]: *** Waiting for unfinished jobs.... > > > > make: *** [Makefile:64: all] Error 2 > > > > > > You need to update libbpf to latest version. > > > > Why not using libbpf from submodule? > > Because it makes it harder for people downloading tarballs and distributions. Genuinely curious, making harder how exactly? When packaging sources as a tarball you'd check out submodules before packaging, right? > Iproute2 has worked well by being standalone. Again, maybe I'm missing something, but what makes it not a standalone, if it is using a submodule? Pahole, for instance, is using libbpf through submodule and just bypasses all the problems with detection of features and library availability. I haven't heard anyone complaining about it made working with pahole harder in any way. > > Want to merge libbpf into iproute2?? No... How did you come to this conclusion?.. > >
On 10/28/20 8:45 PM, Hangbin Liu wrote: > On Wed, Oct 28, 2020 at 08:20:55PM -0600, David Ahern wrote: >>>> root@u2010-sfo3:~/iproute2.git# make -j 4 >>>> ... >>>> /usr/bin/ld: ../lib/libutil.a(bpf_libbpf.o): in function `load_bpf_object': >>>> bpf_libbpf.c:(.text+0x3cb): undefined reference to >>>> `bpf_program__section_name' >>>> /usr/bin/ld: bpf_libbpf.c:(.text+0x438): undefined reference to >>>> `bpf_program__section_name' >>>> /usr/bin/ld: bpf_libbpf.c:(.text+0x716): undefined reference to >>>> `bpf_program__section_name' >>>> collect2: error: ld returned 1 exit status >>>> make[1]: *** [Makefile:27: ip] Error 1 >>>> make[1]: *** Waiting for unfinished jobs.... >>>> make: *** [Makefile:64: all] Error 2 >>> >>> You need to update libbpf to latest version. >> >> nope. you need to be able to handle this. Ubuntu 20.10 was just >> released, and it has a version of libbpf. If you are going to integrate >> libbpf into other packages like iproute2, it needs to just work with >> that version. > > OK, I can replace bpf_program__section_name by bpf_program__title(). I believe this one can be handled through a compatability check. Looks the rename / deprecation is fairly recent (78cdb58bdf15f from Sept 2020). >> >>> >>> But this also remind me that I need to add bpf_program__section_name() to >>> configure checking. I will see if I missed other functions' checking. >> >> This is going to be an on-going problem. iproute2 should work with >> whatever version of libbpf is installed on that system. > > I will make it works on Ubuntu 20.10, but with whatever version of libbpf? > That looks hard, especially with old libbpf. > I meant what comes with the OS. I believe I read that Fedora 33 was just released as well. Does it have a version of libbpf? If so, please verify it compiles and works with that version too. Before committing I will also verify it compiles and links against a local version of libbpf (top of tree) just to get a range of versions.
On Wed, Oct 28, 2020 at 09:00:41PM -0600, David Ahern wrote: > >>> You need to update libbpf to latest version. > >> > >> nope. you need to be able to handle this. Ubuntu 20.10 was just > >> released, and it has a version of libbpf. If you are going to integrate > >> libbpf into other packages like iproute2, it needs to just work with > >> that version. > > > > OK, I can replace bpf_program__section_name by bpf_program__title(). > > I believe this one can be handled through a compatability check. Looks Do you mean add a check like #ifdef has_section_name_support use bpf_program__section_name; #else use bpf_program__title; #endif > the rename / deprecation is fairly recent (78cdb58bdf15f from Sept 2020). Yeah... As Andrii said, libbpf is in fast moving.. > >> > >>> > >>> But this also remind me that I need to add bpf_program__section_name() to > >>> configure checking. I will see if I missed other functions' checking. > >> > >> This is going to be an on-going problem. iproute2 should work with > >> whatever version of libbpf is installed on that system. > > > > I will make it works on Ubuntu 20.10, but with whatever version of libbpf? > > That looks hard, especially with old libbpf. > > > > I meant what comes with the OS. I believe I read that Fedora 33 was just > released as well. Does it have a version of libbpf? If so, please verify > it compiles and works with that version too. Before committing I will > also verify it compiles and links against a local version of libbpf (top > of tree) just to get a range of versions. > Yes, it makes sense. I will also check the libbpf on Fedora 33. Thanks Hangbin
On Wed, Oct 28, 2020 at 09:00:41PM -0600, David Ahern wrote: > >> nope. you need to be able to handle this. Ubuntu 20.10 was just > >> released, and it has a version of libbpf. If you are going to integrate > >> libbpf into other packages like iproute2, it needs to just work with > >> that version. > > > > OK, I can replace bpf_program__section_name by bpf_program__title(). > > I believe this one can be handled through a compatability check. Looks > the rename / deprecation is fairly recent (78cdb58bdf15f from Sept 2020). Hi David, I just come up with another way. In configure, build a temp program and update the function checking every time is not graceful. How about just check the libbpf version, since libbpf has exported all functions in src/libbpf.map. Currently, only bpf_program__section_name() is added in 0.2.0, all other needed functions are supported in 0.1.0. So in configure, the new check would like: check_force_libbpf() { # if set FORCE_LIBBPF but no libbpf support, just exist the config # process to make sure we don't build without libbpf. if [ -n "$FORCE_LIBBPF" ]; then echo "FORCE_LIBBPF set, but couldn't find a usable libbpf" exit 1 fi } check_libbpf() { if ! ${PKG_CONFIG} libbpf --exists && [ -z "$LIBBPF_DIR" ] ; then echo "no" check_force_libbpf return fi if [ $(uname -m) == x86_64 ]; then local LIBSUBDIR=lib64 else local LIBSUBDIR=lib fi if [ -n "$LIBBPF_DIR" ]; then LIBBPF_CFLAGS="-I${LIBBPF_DIR}/include -L${LIBBPF_DIR}/${LIBSUBDIR}" LIBBPF_LDLIBS="${LIBBPF_DIR}/${LIBSUBDIR}/libbpf.a -lz -lelf" else LIBBPF_CFLAGS=$(${PKG_CONFIG} libbpf --cflags) LIBBPF_LDLIBS=$(${PKG_CONFIG} libbpf --libs) fi if ${PKG_CONFIG} libbpf --atleast-version 0.1.0 || \ PKG_CONFIG_LIBDIR=${LIBBPF_DIR}/${LIBSUBDIR}/pkgconfig \ ${PKG_CONFIG} libbpf --atleast-version 0.1.0; then echo "HAVE_LIBBPF:=y" >>$CONFIG echo 'CFLAGS += -DHAVE_LIBBPF ' $LIBBPF_CFLAGS >> $CONFIG echo 'LDLIBS += ' $LIBBPF_LDLIBS >>$CONFIG echo "yes" else echo "no" check_force_libbpf return fi # bpf_program__title() is deprecated since libbpf 0.2.0, use # bpf_program__section_name() instead if we support if ${PKG_CONFIG} libbpf --atleast-version 0.2.0 || \ PKG_CONFIG_LIBDIR=${LIBBPF_DIR}/${LIBSUBDIR}/pkgconfig \ ${PKG_CONFIG} libbpf --atleast-version 0.2.0; then echo 'CFLAGS += -DHAVE_LIBBPF_SECTION_NAME ' $LIBBPF_CFLAGS >> $CONFIG fi } And in lib/bpf_libbpf.c, we add a new helper like: static const char *get_bpf_program__section_name(const struct bpf_program *prog) { #ifdef HAVE_LIBBPF_SECTION_NAME return bpf_program__section_name(prog); #else return bpf_program__title(prog, false); #endif } Thanks Hangbin
Hangbin Liu <haliu@redhat.com> writes: > On Wed, Oct 28, 2020 at 09:00:41PM -0600, David Ahern wrote: >> >> nope. you need to be able to handle this. Ubuntu 20.10 was just >> >> released, and it has a version of libbpf. If you are going to integrate >> >> libbpf into other packages like iproute2, it needs to just work with >> >> that version. >> > >> > OK, I can replace bpf_program__section_name by bpf_program__title(). >> >> I believe this one can be handled through a compatability check. Looks >> the rename / deprecation is fairly recent (78cdb58bdf15f from Sept 2020). > > Hi David, > > I just come up with another way. In configure, build a temp program and update > the function checking every time is not graceful. How about just check the > libbpf version, since libbpf has exported all functions in src/libbpf.map. > > Currently, only bpf_program__section_name() is added in 0.2.0, all other > needed functions are supported in 0.1.0. > > So in configure, the new check would like: Why is this easier than just checking for the function you need? In xdp-tools configure we have a test like this: check_perf_consume() { cat >$TMPDIR/libbpftest.c <<EOF #include <bpf/libbpf.h> int main(int argc, char **argv) { perf_buffer__consume(NULL); return 0; } EOF libbpf_err=$($CC -o $TMPDIR/libbpftest $TMPDIR/libbpftest.c $LIBBPF_CFLAGS $LIBBPF_LDLIBS 2>&1) if [ "$?" -eq "0" ]; then echo "HAVE_LIBBPF_PERF_BUFFER__CONSUME:=y" >>"$CONFIG" echo "yes" else echo "HAVE_LIBBPF_PERF_BUFFER__CONSUME:=n" >>"$CONFIG" echo "no" fi } Just do that for __section_name(), and you'll also be able to work with custom libbpf versions using LIBBPF_DIR. > static const char *get_bpf_program__section_name(const struct bpf_program *prog) > { > #ifdef HAVE_LIBBPF_SECTION_NAME > return bpf_program__section_name(prog); > #else > return bpf_program__title(prog, false); > #endif > } This bit is fine :) -Toke
On Wed, 28 Oct 2020 19:50:51 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > On Wed, Oct 28, 2020 at 7:34 PM Stephen Hemminger > <stephen@networkplumber.org> wrote: > > > > On Wed, 28 Oct 2020 19:27:20 -0700 > > Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > > > > > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > > > > fails to compile on Ubuntu 20.10: > > > > > [...] > > > > You need to update libbpf to latest version. > > > > > > Why not using libbpf from submodule? > > > > Because it makes it harder for people downloading tarballs and distributions. > > Genuinely curious, making harder how exactly? When packaging sources > as a tarball you'd check out submodules before packaging, right? > > > Iproute2 has worked well by being standalone. > > Again, maybe I'm missing something, but what makes it not a > standalone, if it is using a submodule? Pahole, for instance, is using > libbpf through submodule and just bypasses all the problems with > detection of features and library availability. I haven't heard anyone > complaining about it made working with pahole harder in any way. I do believe you are missing something. I guess I can be the relay for complains, so you will officially hear about this. Red Hat and Fedora security is complaining that we are packaging a library (libbpf) directly into the individual packages. They complain because in case of a security issue, they have to figure out to rebuild all the software packages that are statically compiled with this library. Maybe you say I don't care that Distro security teams have to do more work and update more packages. Then security team says, we expect customers will use this library right, and if we ship it as a dynamic loadable (.so) file, then we can update and fix security issues in library without asking customers to recompile. (Notice the same story goes if we can update the base-image used by a container).
On Thu, Oct 29, 2020 at 4:38 AM Jesper Dangaard Brouer <brouer@redhat.com> wrote: > > On Wed, 28 Oct 2020 19:50:51 -0700 > Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > On Wed, Oct 28, 2020 at 7:34 PM Stephen Hemminger > > <stephen@networkplumber.org> wrote: > > > > > > On Wed, 28 Oct 2020 19:27:20 -0700 > > > Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: > > > > > > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote: > > > > > > > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote: > > > > > > fails to compile on Ubuntu 20.10: > > > > > > > [...] > > > > > You need to update libbpf to latest version. > > > > > > > > Why not using libbpf from submodule? > > > > > > Because it makes it harder for people downloading tarballs and distributions. > > > > Genuinely curious, making harder how exactly? When packaging sources > > as a tarball you'd check out submodules before packaging, right? > > > > > Iproute2 has worked well by being standalone. > > > > Again, maybe I'm missing something, but what makes it not a > > standalone, if it is using a submodule? Pahole, for instance, is using > > libbpf through submodule and just bypasses all the problems with > > detection of features and library availability. I haven't heard anyone > > complaining about it made working with pahole harder in any way. > > I do believe you are missing something. I don't think I got an answer how submodules make it harder for people downloading tarballs and distributions, and the standalone-ness issue. Your security angle is a very different aspect. > I guess I can be the relay for > complains, so you will officially hear about this. Red Hat and Fedora > security is complaining that we are packaging a library (libbpf) > directly into the individual packages. They complain because in case > of a security issue, they have to figure out to rebuild all the software > packages that are statically compiled with this library. They must be having nightmares already about BCC, bpftool, pahole, as well as perf built with libbpf statically (perf on my server is, at least). I also wonder how many other projects do use either submodules or static linking with libraries as well. > > Maybe you say I don't care that Distro security teams have to do more > work and update more packages. Then security team says, we expect > customers will use this library right, and if we ship it as a dynamic > loadable (.so) file, then we can update and fix security issues in > library without asking customers to recompile. (Notice the same story > goes if we can update the base-image used by a container). It's a trade off, and everyone decides for themselves where they want to stand on this. On the one hand, there are security folks obsessing about hypothetical security vulnerabilities in libbpf so bad that they will need to update libbpf overnight. On the other hand, extra complexity for multiple users of libbpf to do feature detection and working around the lack of some of the APIs in libbpf due to older versions in the system. That extra complexity might lead to more problems, bugs, vulnerabilities in the long run. I understand the concerns and how dynamic libraries make it easier. We can't really know for sure which of those two aspects would lead to more pain and problems overall. I personally choose simplicity, though. But as I said, it's up to iproute2 folks to decide. Was just curious about some of the claims I cited. > > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > LinkedIn: http://www.linkedin.com/in/brouer >