Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > libbpf 1.0 was a major change in API. Perf has partially supported
> > older libbpf's but an implementation may be:
> > ..
> > pr_err("%s: not support, update libbpf\n", __func__);
> > return -ENOTSUP;
> > ..
> >
> > Rather than build a binary that would fail at runtime it is
> > preferrential just to build libbpf statically and link against
> > that. The static version is in the kernel tools tree and newer than
> > 1.0.
> >
> > These patches change the libbpf test to only pass when at least
> > version 1.0 is installed, then remove the conditional build and
> > feature logic.
> >
> > The issue is discussed here:
> > https://lore.kernel.org/lkml/[email protected]/
> > perf bpf:
> >
> > A variant of this fix was added to Linux 6.2 in:
> > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > https://lore.kernel.org/lkml/[email protected]/
> > This change goes further in removing logic that is now no longer
> > necessary.
> >
> > v2. Rebase now that breakage fix patch is in linus/master.
>
> I missed the:
> Acked/Tested-by: Jiri Olsa <[email protected]>
> I believe we are waiting for package maintainer input.
Yes, as fedora:37 still is at libbpf 0.8.0 :-\
This is what I have in the containers I test, sure, the older ones
already have NO_LIBBPF=1 and some will get this added, and some I still
need to ask for libbpf-devel (or the distro specific name, like
libbpf-dev):
[perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
[perfbuilder@five ~]$
[perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
debian/experimental/Dockerfile: libbpf-dev \
fedora/35/Dockerfile: libtraceevent-devel libbpf-devel \
fedora/36/Dockerfile: libtraceevent-devel libbpf-devel \
fedora/37/Dockerfile: libtraceevent-devel libbpf-devel \
fedora/38/Dockerfile: libtraceevent-devel libbpf-devel \
fedora/rawhide/Dockerfile: libtraceevent-devel libbpf-devel \
opensuse/tumbleweed/Dockerfile: libbpf-devel libtraceevent-devel \
ubuntu/22.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
ubuntu/22.10/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
ubuntu/23.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
[perfbuilder@five linux-perf-tools-build]$
In some cases it gets dragged on differently, like with clearlinux,
gentoo, archlinux, etc.
Anyway, just a data point, I'll check if I'm missing installing it
somewhere.
- Arnaldo
Em Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> Anyway, just a data point, I'll check if I'm missing installing it
> somewhere.
Just asked for libbpf-dev to be installed on the debian:11 container:
[perfbuilder@five 11]$ dsh debian:11
$ bash
perfbuilder@589d1572e8cf:/$ ls -la /usr/lib/x86_64-linux-gnu/libbpf.so.0
lrwxrwxrwx. 1 root root 15 Jan 10 2021 /usr/lib/x86_64-linux-gnu/libbpf.so.0 -> libbpf.so.0.3.0
perfbuilder@589d1572e8cf:/$ dpkg -l | grep bpf
ii libbpf-dev:amd64 1:0.3-2 amd64 eBPF helper library (development files)
ii libbpf0:amd64 1:0.3-2 amd64 eBPF helper library (shared library)
ii libpfm4:amd64 4.11.1+git32-gd0b85fb-1 amd64 Library to program the performance monitoring events
perfbuilder@589d1572e8cf:/$
- Arnaldo
On Thu, Jan 19, 2023 at 9:47 AM Arnaldo Carvalho de Melo
<[email protected]> wrote:
>
> Em Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Anyway, just a data point, I'll check if I'm missing installing it
> > somewhere.
>
> Just asked for libbpf-dev to be installed on the debian:11 container:
>
> [perfbuilder@five 11]$ dsh debian:11
> $ bash
> perfbuilder@589d1572e8cf:/$ ls -la /usr/lib/x86_64-linux-gnu/libbpf.so.0
> lrwxrwxrwx. 1 root root 15 Jan 10 2021 /usr/lib/x86_64-linux-gnu/libbpf.so.0 -> libbpf.so.0.3.0
> perfbuilder@589d1572e8cf:/$ dpkg -l | grep bpf
> ii libbpf-dev:amd64 1:0.3-2 amd64 eBPF helper library (development files)
> ii libbpf0:amd64 1:0.3-2 amd64 eBPF helper library (shared library)
> ii libpfm4:amd64 4.11.1+git32-gd0b85fb-1 amd64 Library to program the performance monitoring events
> perfbuilder@589d1572e8cf:/$
>
> - Arnaldo
Right, the old/ancient libbpf-s are gross, but Debian doesn't use
LIBBPF_DYNAMIC which also isn't a default build option. I guess we
could say there's some testing impact from this cleanup, but I'm not
sure we care.
Thanks,
Ian
On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > older libbpf's but an implementation may be:
> > > ..
> > > pr_err("%s: not support, update libbpf\n", __func__);
> > > return -ENOTSUP;
> > > ..
> > >
> > > Rather than build a binary that would fail at runtime it is
> > > preferrential just to build libbpf statically and link against
> > > that. The static version is in the kernel tools tree and newer than
> > > 1.0.
> > >
> > > These patches change the libbpf test to only pass when at least
> > > version 1.0 is installed, then remove the conditional build and
> > > feature logic.
> > >
> > > The issue is discussed here:
> > > https://lore.kernel.org/lkml/[email protected]/
> > > perf bpf:
> > >
> > > A variant of this fix was added to Linux 6.2 in:
> > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > https://lore.kernel.org/lkml/[email protected]/
> > > This change goes further in removing logic that is now no longer
> > > necessary.
> > >
> > > v2. Rebase now that breakage fix patch is in linus/master.
> >
> > I missed the:
> > Acked/Tested-by: Jiri Olsa <[email protected]>
> > I believe we are waiting for package maintainer input.
>
> Yes, as fedora:37 still is at libbpf 0.8.0 :-\
rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
for f38, so not sure how bad it'd be for f37
jirka
>
> This is what I have in the containers I test, sure, the older ones
> already have NO_LIBBPF=1 and some will get this added, and some I still
> need to ask for libbpf-devel (or the distro specific name, like
> libbpf-dev):
>
> [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> [perfbuilder@five ~]$
>
> [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> debian/experimental/Dockerfile: libbpf-dev \
> fedora/35/Dockerfile: libtraceevent-devel libbpf-devel \
> fedora/36/Dockerfile: libtraceevent-devel libbpf-devel \
> fedora/37/Dockerfile: libtraceevent-devel libbpf-devel \
> fedora/38/Dockerfile: libtraceevent-devel libbpf-devel \
> fedora/rawhide/Dockerfile: libtraceevent-devel libbpf-devel \
> opensuse/tumbleweed/Dockerfile: libbpf-devel libtraceevent-devel \
> ubuntu/22.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> ubuntu/22.10/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> ubuntu/23.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> [perfbuilder@five linux-perf-tools-build]$
>
> In some cases it gets dragged on differently, like with clearlinux,
> gentoo, archlinux, etc.
>
> Anyway, just a data point, I'll check if I'm missing installing it
> somewhere.
>
> - Arnaldo
On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
>
> On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > older libbpf's but an implementation may be:
> > > > ..
> > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > return -ENOTSUP;
> > > > ..
> > > >
> > > > Rather than build a binary that would fail at runtime it is
> > > > preferrential just to build libbpf statically and link against
> > > > that. The static version is in the kernel tools tree and newer than
> > > > 1.0.
> > > >
> > > > These patches change the libbpf test to only pass when at least
> > > > version 1.0 is installed, then remove the conditional build and
> > > > feature logic.
> > > >
> > > > The issue is discussed here:
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > > perf bpf:
> > > >
> > > > A variant of this fix was added to Linux 6.2 in:
> > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > > This change goes further in removing logic that is now no longer
> > > > necessary.
> > > >
> > > > v2. Rebase now that breakage fix patch is in linus/master.
> > >
> > > I missed the:
> > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > I believe we are waiting for package maintainer input.
> >
> > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
>
> rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> for f38, so not sure how bad it'd be for f37
>
> jirka
+Guilherme
We were looking for maintainer input on these changes, but there is no
update in over a month. Here is the original lore link:
https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
Should these changes land in perf-tools-next targeting Linux 6.4?
Thanks,
Ian
> >
> > This is what I have in the containers I test, sure, the older ones
> > already have NO_LIBBPF=1 and some will get this added, and some I still
> > need to ask for libbpf-devel (or the distro specific name, like
> > libbpf-dev):
> >
> > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > [perfbuilder@five ~]$
> >
> > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > debian/experimental/Dockerfile: libbpf-dev \
> > fedora/35/Dockerfile: libtraceevent-devel libbpf-devel \
> > fedora/36/Dockerfile: libtraceevent-devel libbpf-devel \
> > fedora/37/Dockerfile: libtraceevent-devel libbpf-devel \
> > fedora/38/Dockerfile: libtraceevent-devel libbpf-devel \
> > fedora/rawhide/Dockerfile: libtraceevent-devel libbpf-devel \
> > opensuse/tumbleweed/Dockerfile: libbpf-devel libtraceevent-devel \
> > ubuntu/22.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > ubuntu/22.10/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > ubuntu/23.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > [perfbuilder@five linux-perf-tools-build]$
> >
> > In some cases it gets dragged on differently, like with clearlinux,
> > gentoo, archlinux, etc.
> >
> > Anyway, just a data point, I'll check if I'm missing installing it
> > somewhere.
> >
> > - Arnaldo
On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> >
> > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > older libbpf's but an implementation may be:
> > > > > ..
> > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > return -ENOTSUP;
> > > > > ..
> > > > >
> > > > > Rather than build a binary that would fail at runtime it is
> > > > > preferrential just to build libbpf statically and link against
> > > > > that. The static version is in the kernel tools tree and newer than
> > > > > 1.0.
> > > > >
> > > > > These patches change the libbpf test to only pass when at least
> > > > > version 1.0 is installed, then remove the conditional build and
> > > > > feature logic.
> > > > >
> > > > > The issue is discussed here:
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > perf bpf:
> > > > >
> > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > This change goes further in removing logic that is now no longer
> > > > > necessary.
> > > > >
> > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > >
> > > > I missed the:
> > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > I believe we are waiting for package maintainer input.
> > >
> > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> >
> > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > for f38, so not sure how bad it'd be for f37
> >
> > jirka
>
> +Guilherme
>
> We were looking for maintainer input on these changes, but there is no
> update in over a month. Here is the original lore link:
> https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> Should these changes land in perf-tools-next targeting Linux 6.4?
Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
Best regards,
-Guilherme
On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <[email protected]> wrote:
>
> On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > >
> > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > older libbpf's but an implementation may be:
> > > > > > ..
> > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > return -ENOTSUP;
> > > > > > ..
> > > > > >
> > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > preferrential just to build libbpf statically and link against
> > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > 1.0.
> > > > > >
> > > > > > These patches change the libbpf test to only pass when at least
> > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > feature logic.
> > > > > >
> > > > > > The issue is discussed here:
> > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > perf bpf:
> > > > > >
> > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > This change goes further in removing logic that is now no longer
> > > > > > necessary.
> > > > > >
> > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > >
> > > > > I missed the:
> > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > I believe we are waiting for package maintainer input.
> > > >
> > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > >
> > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > for f38, so not sure how bad it'd be for f37
> > >
> > > jirka
> >
> > +Guilherme
> >
> > We were looking for maintainer input on these changes, but there is no
> > update in over a month. Here is the original lore link:
> > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > Should these changes land in perf-tools-next targeting Linux 6.4?
>
> Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
>
libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
APIs that are in 1.0 (except newer one added later, but I'm not sure
perf needs any of the newer additions), and just stick to setting
libbpf_set_strict_mode() unconditionally.
> Best regards,
> -Guilherme
>
On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
<[email protected]> wrote:
>
> On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <[email protected]> wrote:
> >
> > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > > >
> > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > older libbpf's but an implementation may be:
> > > > > > > ..
> > > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > return -ENOTSUP;
> > > > > > > ..
> > > > > > >
> > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > 1.0.
> > > > > > >
> > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > feature logic.
> > > > > > >
> > > > > > > The issue is discussed here:
> > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > perf bpf:
> > > > > > >
> > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > necessary.
> > > > > > >
> > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > >
> > > > > > I missed the:
> > > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > > I believe we are waiting for package maintainer input.
> > > > >
> > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > >
> > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > for f38, so not sure how bad it'd be for f37
> > > >
> > > > jirka
> > >
> > > +Guilherme
> > >
> > > We were looking for maintainer input on these changes, but there is no
> > > update in over a month. Here is the original lore link:
> > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > Should these changes land in perf-tools-next targeting Linux 6.4?
> >
> > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> >
>
> libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
>
> So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> APIs that are in 1.0 (except newer one added later, but I'm not sure
> perf needs any of the newer additions), and just stick to setting
> libbpf_set_strict_mode() unconditionally.
Thanks Andrii,
The default perf build is to build against tools/lib/bpf and
statically link libbpf in. This means by default we have the latest
libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
earlier) we need to #ifdef for it. Currently we have 7 feature tests
for libbpf, but perhaps there is some cruft that's carried forward.
The features are:
- btf__load_from_kernel_by_id
- bpf_prog_load
- bpf_object__next_program
- bpf_object__next_map
- bpf_program__set_insns
- btf__raw_data
- bpf_map_create
The not present implementations look like:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
```
int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
{
pr_err("%s: not support, update libbpf\n", __func__);
return -ENOTSUP;
}
int libbpf_register_prog_handler(const char *sec __maybe_unused,
enum bpf_prog_type prog_type __maybe_unused,
enum bpf_attach_type exp_attach_type
__maybe_unused,
const struct libbpf_prog_handler_opts
*opts __maybe_unused)
{
pr_err("%s: not support, update libbpf\n", __func__);
return -ENOTSUP;
}
```
This will basically mean that while you dynamically linked with libbpf
0.8 you are in all likelihood not going to get proper BPF support.
These changes up the version requirement to 1.0 and get rid entirely
of the feature tests - so no runtime failing implementations. If the
build determines at build time libbpf 1.0+ isn't present then it still
executes, switching from dynamic libbpf to the default static libbpf
that is at 1.2. As mentioned in this thread, distributions like Debian
use the default static linking of libbpf.
I'm not keen to hold on to the feature tests for the complexity that
they hold and their needlessly (as you can always statically link)
broken at runtime behavior. We could but my opinion is, let's not :-)
Thanks,
Ian
> > Best regards,
> > -Guilherme
> >
On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> >
> > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > older libbpf's but an implementation may be:
> > > > > ..
> > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > return -ENOTSUP;
> > > > > ..
> > > > >
> > > > > Rather than build a binary that would fail at runtime it is
> > > > > preferrential just to build libbpf statically and link against
> > > > > that. The static version is in the kernel tools tree and newer than
> > > > > 1.0.
> > > > >
> > > > > These patches change the libbpf test to only pass when at least
> > > > > version 1.0 is installed, then remove the conditional build and
> > > > > feature logic.
> > > > >
> > > > > The issue is discussed here:
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > perf bpf:
> > > > >
> > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > This change goes further in removing logic that is now no longer
> > > > > necessary.
> > > > >
> > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > >
> > > > I missed the:
> > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > I believe we are waiting for package maintainer input.
> > >
> > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> >
> > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > for f38, so not sure how bad it'd be for f37
> >
> > jirka
>
> +Guilherme
>
> We were looking for maintainer input on these changes, but there is no
> update in over a month. Here is the original lore link:
> https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> Should these changes land in perf-tools-next targeting Linux 6.4?
ugh, I did not include Justin :-\ sry
Justin,
we are trying to move perf to use libbpf 1.0 only, which is fine for fedora 38,
but fedora 37 is still on libbpf 0.8 (and it's not easy to do the bulk update)
would fedora 37 even get to sync 6.4 kernel/kernel-tools?
thanks,
jirka
>
> Thanks,
> Ian
>
> > >
> > > This is what I have in the containers I test, sure, the older ones
> > > already have NO_LIBBPF=1 and some will get this added, and some I still
> > > need to ask for libbpf-devel (or the distro specific name, like
> > > libbpf-dev):
> > >
> > > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > [perfbuilder@five ~]$
> > >
> > > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > > debian/experimental/Dockerfile: libbpf-dev \
> > > fedora/35/Dockerfile: libtraceevent-devel libbpf-devel \
> > > fedora/36/Dockerfile: libtraceevent-devel libbpf-devel \
> > > fedora/37/Dockerfile: libtraceevent-devel libbpf-devel \
> > > fedora/38/Dockerfile: libtraceevent-devel libbpf-devel \
> > > fedora/rawhide/Dockerfile: libtraceevent-devel libbpf-devel \
> > > opensuse/tumbleweed/Dockerfile: libbpf-devel libtraceevent-devel \
> > > ubuntu/22.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > ubuntu/22.10/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > ubuntu/23.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > [perfbuilder@five linux-perf-tools-build]$
> > >
> > > In some cases it gets dragged on differently, like with clearlinux,
> > > gentoo, archlinux, etc.
> > >
> > > Anyway, just a data point, I'll check if I'm missing installing it
> > > somewhere.
> > >
> > > - Arnaldo
On Fri, Mar 10, 2023 at 3:09 AM Jiri Olsa <[email protected]> wrote:
>
> On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > >
> > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > older libbpf's but an implementation may be:
> > > > > > ..
> > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > return -ENOTSUP;
> > > > > > ..
> > > > > >
> > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > preferrential just to build libbpf statically and link against
> > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > 1.0.
> > > > > >
> > > > > > These patches change the libbpf test to only pass when at least
> > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > feature logic.
> > > > > >
> > > > > > The issue is discussed here:
> > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > perf bpf:
> > > > > >
> > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > This change goes further in removing logic that is now no longer
> > > > > > necessary.
> > > > > >
> > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > >
> > > > > I missed the:
> > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > I believe we are waiting for package maintainer input.
> > > >
> > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > >
> > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > for f38, so not sure how bad it'd be for f37
> > >
> > > jirka
> >
> > +Guilherme
> >
> > We were looking for maintainer input on these changes, but there is no
> > update in over a month. Here is the original lore link:
> > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > Should these changes land in perf-tools-next targeting Linux 6.4?
>
> ugh, I did not include Justin :-\ sry
>
> Justin,
> we are trying to move perf to use libbpf 1.0 only, which is fine for fedora 38,
> but fedora 37 is still on libbpf 0.8 (and it's not easy to do the bulk update)
>
> would fedora 37 even get to sync 6.4 kernel/kernel-tools?
Yes, Fedora 37 will not EOL until November when F39 has been out for
30 days. It will certainly get 6.4, which should come out this summer.
We could probably do some hackish static link situation for Fedora 37
if necessary though. It isn't idea, but we know it is short lived, so
I would be okay with making that work.
Justin
> thanks,
> jirka
>
> >
> > Thanks,
> > Ian
> >
> > > >
> > > > This is what I have in the containers I test, sure, the older ones
> > > > already have NO_LIBBPF=1 and some will get this added, and some I still
> > > > need to ask for libbpf-devel (or the distro specific name, like
> > > > libbpf-dev):
> > > >
> > > > [perfbuilder@five ~]$ podman images --format "{{.Repository}}:{{.Tag}}" | grep /acmel/ | grep -v '<none>' | sort -t: -Vk1,2 | grep -v -- -x- | while read image ; do echo -n $image: ; libbpf=$(podman run --rm -t --entrypoint=ls $image -la /usr/lib64/libbpf.so.1) ; echo $libbpf ; done
> > > > localhost/acmel/linux-perf-tools-build-almalinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-almalinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.12:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.13:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.14:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.15:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.16:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:3.17:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alpine:edge:ls: /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:p9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:p10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-alt:sisyphus:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-amazonlinux:2:ls: cannot access /usr/lib64/libbpf.so.1: No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-amazonlinux:devel:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-archlinux:base:lrwxrwxrwx 1 root root 15 Oct 1 12:32 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-centos:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-centos:stream:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-clearlinux:latest:lrwxrwxrwx 1 root root 15 Sep 30 16:01 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-debian:10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-debian:11:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-debian:experimental:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:26:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:27:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:28:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:29:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:30:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:31:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:32:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:33:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:34:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:35:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:36:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:37:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-fedora:38:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > > localhost/acmel/linux-perf-tools-build-fedora:rawhide:lrwxrwxrwx. 1 root root 15 Dec 20 14:39 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.0
> > > > localhost/acmel/linux-perf-tools-build-gentoo-stage3:latest:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-manjaro:base:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.0:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.1:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.2:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.3:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.4:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:15.5:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-opensuse:tumbleweed:lrwxrwxrwx. 1 root root 15 Nov 9 12:08 /usr/lib64/libbpf.so.1 -> libbpf.so.1.0.1
> > > > localhost/acmel/linux-perf-tools-build-oraclelinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-oraclelinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-rockylinux:8:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-rockylinux:9:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:18.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:20.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:21.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:21.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:22.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:22.10:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > localhost/acmel/linux-perf-tools-build-ubuntu:23.04:ls: cannot access '/usr/lib64/libbpf.so.1': No such file or directory
> > > > [perfbuilder@five ~]$
> > > >
> > > > [perfbuilder@five linux-perf-tools-build]$ grep libbpf-dev */*/Dockerfile
> > > > debian/experimental/Dockerfile: libbpf-dev \
> > > > fedora/35/Dockerfile: libtraceevent-devel libbpf-devel \
> > > > fedora/36/Dockerfile: libtraceevent-devel libbpf-devel \
> > > > fedora/37/Dockerfile: libtraceevent-devel libbpf-devel \
> > > > fedora/38/Dockerfile: libtraceevent-devel libbpf-devel \
> > > > fedora/rawhide/Dockerfile: libtraceevent-devel libbpf-devel \
> > > > opensuse/tumbleweed/Dockerfile: libbpf-devel libtraceevent-devel \
> > > > ubuntu/22.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > ubuntu/22.10/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > ubuntu/23.04/Dockerfile: libelf-dev libiberty-dev libdw-dev libaudit-dev libtraceevent-dev libbpf-dev \
> > > > [perfbuilder@five linux-perf-tools-build]$
> > > >
> > > > In some cases it gets dragged on differently, like with clearlinux,
> > > > gentoo, archlinux, etc.
> > > >
> > > > Anyway, just a data point, I'll check if I'm missing installing it
> > > > somewhere.
> > > >
> > > > - Arnaldo
>
On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <[email protected]> wrote:
>
> On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> <[email protected]> wrote:
> >
> > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <[email protected]> wrote:
> > >
> > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > > > >
> > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > ..
> > > > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > > return -ENOTSUP;
> > > > > > > > ..
> > > > > > > >
> > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > 1.0.
> > > > > > > >
> > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > feature logic.
> > > > > > > >
> > > > > > > > The issue is discussed here:
> > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > perf bpf:
> > > > > > > >
> > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > necessary.
> > > > > > > >
> > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > >
> > > > > > > I missed the:
> > > > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > > > I believe we are waiting for package maintainer input.
> > > > > >
> > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > >
> > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > for f38, so not sure how bad it'd be for f37
> > > > >
> > > > > jirka
> > > >
> > > > +Guilherme
> > > >
> > > > We were looking for maintainer input on these changes, but there is no
> > > > update in over a month. Here is the original lore link:
> > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > >
> > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > >
> >
> > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> >
> > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > perf needs any of the newer additions), and just stick to setting
> > libbpf_set_strict_mode() unconditionally.
>
> Thanks Andrii,
>
Full disclosure, I'm totally supporting the switch to v1.0+, just
trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
transition. See below. I believe you can keep 0.8+ dependency and drop
all the legacy code completely.
But just take it as an information, and feel free to do whatever you
think is best with it.
> The default perf build is to build against tools/lib/bpf and
> statically link libbpf in. This means by default we have the latest
> libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> earlier) we need to #ifdef for it. Currently we have 7 feature tests
> for libbpf, but perhaps there is some cruft that's carried forward.
> The features are:
> - btf__load_from_kernel_by_id
v0.5 API
> - bpf_prog_load
> - bpf_object__next_program
> - bpf_object__next_map
all three are v0.6 APIs
> - bpf_program__set_insns
v0.8 API
> - btf__raw_data
> - bpf_map_create
both v0.6 API
>
> The not present implementations look like:
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> ```
> int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
> struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> {
> pr_err("%s: not support, update libbpf\n", __func__);
> return -ENOTSUP;
> }
>
> int libbpf_register_prog_handler(const char *sec __maybe_unused,
> enum bpf_prog_type prog_type __maybe_unused,
> enum bpf_attach_type exp_attach_type
> __maybe_unused,
> const struct libbpf_prog_handler_opts
> *opts __maybe_unused)
> {
> pr_err("%s: not support, update libbpf\n", __func__);
> return -ENOTSUP;
> }
> ```
both are v0.8 APIs
> This will basically mean that while you dynamically linked with libbpf
> 0.8 you are in all likelihood not going to get proper BPF support.
> These changes up the version requirement to 1.0 and get rid entirely
> of the feature tests - so no runtime failing implementations. If the
100% supportive on upgrade and dropping feature checks. My point is
that you don't need those feature checks with v0.8+ requirement.
The only difference between staying on v0.8+ vs going all the way to
v1.0+ would be that you have to keep libbpf_set_strict() call. In
v1.0+ it's a noop, so could be dropped.
> build determines at build time libbpf 1.0+ isn't present then it still
> executes, switching from dynamic libbpf to the default static libbpf
> that is at 1.2. As mentioned in this thread, distributions like Debian
> use the default static linking of libbpf.
>
oh, that's nice, good to know
> I'm not keen to hold on to the feature tests for the complexity that
> they hold and their needlessly (as you can always statically link)
> broken at runtime behavior. We could but my opinion is, let's not :-)
I've been consistently advocating for static linking with libbpf, so
100% support this.
>
> Thanks,
> Ian
>
> > > Best regards,
> > > -Guilherme
> > >
On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
<[email protected]> wrote:
>
> On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <[email protected]> wrote:
> >
> > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > <[email protected]> wrote:
> > >
> > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <[email protected]> wrote:
> > > >
> > > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > > > > >
> > > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > > ..
> > > > > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > > > return -ENOTSUP;
> > > > > > > > > ..
> > > > > > > > >
> > > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > > 1.0.
> > > > > > > > >
> > > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > > feature logic.
> > > > > > > > >
> > > > > > > > > The issue is discussed here:
> > > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > > perf bpf:
> > > > > > > > >
> > > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > > necessary.
> > > > > > > > >
> > > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > > >
> > > > > > > > I missed the:
> > > > > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > > > > I believe we are waiting for package maintainer input.
> > > > > > >
> > > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > > >
> > > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > > for f38, so not sure how bad it'd be for f37
> > > > > >
> > > > > > jirka
> > > > >
> > > > > +Guilherme
> > > > >
> > > > > We were looking for maintainer input on these changes, but there is no
> > > > > update in over a month. Here is the original lore link:
> > > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > > >
> > > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > > >
> > >
> > > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> > >
> > > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > > perf needs any of the newer additions), and just stick to setting
> > > libbpf_set_strict_mode() unconditionally.
> >
> > Thanks Andrii,
> >
>
> Full disclosure, I'm totally supporting the switch to v1.0+, just
> trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
> transition. See below. I believe you can keep 0.8+ dependency and drop
> all the legacy code completely.
>
> But just take it as an information, and feel free to do whatever you
> think is best with it.
>
> > The default perf build is to build against tools/lib/bpf and
> > statically link libbpf in. This means by default we have the latest
> > libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> > earlier) we need to #ifdef for it. Currently we have 7 feature tests
> > for libbpf, but perhaps there is some cruft that's carried forward.
> > The features are:
> > - btf__load_from_kernel_by_id
>
> v0.5 API
>
> > - bpf_prog_load
> > - bpf_object__next_program
> > - bpf_object__next_map
>
> all three are v0.6 APIs
>
> > - bpf_program__set_insns
>
> v0.8 API
>
> > - btf__raw_data
> > - bpf_map_create
>
> both v0.6 API
>
> >
> > The not present implementations look like:
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> > ```
> > int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
> > struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> > {
> > pr_err("%s: not support, update libbpf\n", __func__);
> > return -ENOTSUP;
> > }
> >
> > int libbpf_register_prog_handler(const char *sec __maybe_unused,
> > enum bpf_prog_type prog_type __maybe_unused,
> > enum bpf_attach_type exp_attach_type
> > __maybe_unused,
> > const struct libbpf_prog_handler_opts
> > *opts __maybe_unused)
> > {
> > pr_err("%s: not support, update libbpf\n", __func__);
> > return -ENOTSUP;
> > }
> > ```
>
> both are v0.8 APIs
>
> > This will basically mean that while you dynamically linked with libbpf
> > 0.8 you are in all likelihood not going to get proper BPF support.
> > These changes up the version requirement to 1.0 and get rid entirely
> > of the feature tests - so no runtime failing implementations. If the
>
> 100% supportive on upgrade and dropping feature checks. My point is
> that you don't need those feature checks with v0.8+ requirement.
>
> The only difference between staying on v0.8+ vs going all the way to
> v1.0+ would be that you have to keep libbpf_set_strict() call. In
> v1.0+ it's a noop, so could be dropped.
>
> > build determines at build time libbpf 1.0+ isn't present then it still
> > executes, switching from dynamic libbpf to the default static libbpf
> > that is at 1.2. As mentioned in this thread, distributions like Debian
> > use the default static linking of libbpf.
> >
>
> oh, that's nice, good to know
>
> > I'm not keen to hold on to the feature tests for the complexity that
> > they hold and their needlessly (as you can always statically link)
> > broken at runtime behavior. We could but my opinion is, let's not :-)
>
> I've been consistently advocating for static linking with libbpf, so
> 100% support this.
Right, so I think we should move forward with these patches. We also
have had non-API changes to support libbpf 1.0+ like:
https://lore.kernel.org/lkml/[email protected]/
and I'm worried about the state of these with libbpf 0.8.
Thanks,
Ian
> >
> > Thanks,
> > Ian
> >
> > > > Best regards,
> > > > -Guilherme
> > > >
On Sat, Mar 11, 2023 at 05:00:01PM -0800, Ian Rogers wrote:
> On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
> <[email protected]> wrote:
> >
> > On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <[email protected]> wrote:
> > >
> > > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > > <[email protected]> wrote:
> > > >
> > > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <[email protected]> wrote:
> > > > >
> > > > > On Wed, Mar 08, 2023 at 06:13:34PM -0800, Ian Rogers wrote:
> > > > > > On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <[email protected]> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 19, 2023 at 02:41:12PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > > > Em Thu, Jan 19, 2023 at 09:11:03AM -0800, Ian Rogers escreveu:
> > > > > > > > > On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <[email protected]> wrote:
> > > > > > > > > > libbpf 1.0 was a major change in API. Perf has partially supported
> > > > > > > > > > older libbpf's but an implementation may be:
> > > > > > > > > > ..
> > > > > > > > > > pr_err("%s: not support, update libbpf\n", __func__);
> > > > > > > > > > return -ENOTSUP;
> > > > > > > > > > ..
> > > > > > > > > >
> > > > > > > > > > Rather than build a binary that would fail at runtime it is
> > > > > > > > > > preferrential just to build libbpf statically and link against
> > > > > > > > > > that. The static version is in the kernel tools tree and newer than
> > > > > > > > > > 1.0.
> > > > > > > > > >
> > > > > > > > > > These patches change the libbpf test to only pass when at least
> > > > > > > > > > version 1.0 is installed, then remove the conditional build and
> > > > > > > > > > feature logic.
> > > > > > > > > >
> > > > > > > > > > The issue is discussed here:
> > > > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > > > perf bpf:
> > > > > > > > > >
> > > > > > > > > > A variant of this fix was added to Linux 6.2 in:
> > > > > > > > > > "perf bpf: Avoid build breakage with libbpf < 0.8.0 + LIBBPF_DYNAMIC=1"
> > > > > > > > > > https://lore.kernel.org/lkml/[email protected]/
> > > > > > > > > > This change goes further in removing logic that is now no longer
> > > > > > > > > > necessary.
> > > > > > > > > >
> > > > > > > > > > v2. Rebase now that breakage fix patch is in linus/master.
> > > > > > > > >
> > > > > > > > > I missed the:
> > > > > > > > > Acked/Tested-by: Jiri Olsa <[email protected]>
> > > > > > > > > I believe we are waiting for package maintainer input.
> > > > > > > >
> > > > > > > > Yes, as fedora:37 still is at libbpf 0.8.0 :-\
> > > > > > >
> > > > > > > rawhide (f38) is already on 1.1.0 ... I'll check how bad it'd be to move
> > > > > > > f37 to 1.x, but I had to do bulk update of like 10 other dependent packages
> > > > > > > for f38, so not sure how bad it'd be for f37
> > > > > > >
> > > > > > > jirka
> > > > > >
> > > > > > +Guilherme
> > > > > >
> > > > > > We were looking for maintainer input on these changes, but there is no
> > > > > > update in over a month. Here is the original lore link:
> > > > > > https://lore.kernel.org/lkml/CAP-5=fVUgc8xtBzGi66YRUxZHyXvW2kiMjGz39dywaLxrO4Hpg@mail.gmail.com/
> > > > > > Should these changes land in perf-tools-next targeting Linux 6.4?
> > > > >
> > > > > Gentoo has libbpf-1.1 already available, so requiring >libbpf-1.0 is not
> > > > > a problem. We (Gentoo) just need to make sure to stabilize libbpf-1.x before
> > > > > stabilizing newer versions of perf, as the stable libbpf is 0.8.1 at the moment.
> > > > >
> > > >
> > > > libbpf v0.8 is basically all the 1.0 APIs, except by default 1.0
> > > > semantics is not enforced, unless libbpf_set_strict_mode() is enabled.
> > > >
> > > > So, if 0.8 is a restriction, perf can stay on 0.8, use all the same
> > > > APIs that are in 1.0 (except newer one added later, but I'm not sure
> > > > perf needs any of the newer additions), and just stick to setting
> > > > libbpf_set_strict_mode() unconditionally.
> > >
> > > Thanks Andrii,
> > >
> >
> > Full disclosure, I'm totally supporting the switch to v1.0+, just
> > trying to be helpful here from the standpoint of 0.x vs 1.x libbpf
> > transition. See below. I believe you can keep 0.8+ dependency and drop
> > all the legacy code completely.
> >
> > But just take it as an information, and feel free to do whatever you
> > think is best with it.
> >
> > > The default perf build is to build against tools/lib/bpf and
> > > statically link libbpf in. This means by default we have the latest
> > > libbpf 1.2. If any perf code has a dependency on 0.8 (we don't support
> > > earlier) we need to #ifdef for it. Currently we have 7 feature tests
> > > for libbpf, but perhaps there is some cruft that's carried forward.
> > > The features are:
> > > - btf__load_from_kernel_by_id
> >
> > v0.5 API
> >
> > > - bpf_prog_load
> > > - bpf_object__next_program
> > > - bpf_object__next_map
> >
> > all three are v0.6 APIs
> >
> > > - bpf_program__set_insns
> >
> > v0.8 API
> >
> > > - btf__raw_data
> > > - bpf_map_create
> >
> > both v0.6 API
> >
> > >
> > > The not present implementations look like:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/bpf-loader.c?h=perf-tools#n36
> > > ```
> > > int bpf_program__set_insns(struct bpf_program *prog __maybe_unused,
> > > struct bpf_insn *new_insns __maybe_unused, size_t new_insn_cnt __maybe_unused)
> > > {
> > > pr_err("%s: not support, update libbpf\n", __func__);
> > > return -ENOTSUP;
> > > }
> > >
> > > int libbpf_register_prog_handler(const char *sec __maybe_unused,
> > > enum bpf_prog_type prog_type __maybe_unused,
> > > enum bpf_attach_type exp_attach_type
> > > __maybe_unused,
> > > const struct libbpf_prog_handler_opts
> > > *opts __maybe_unused)
> > > {
> > > pr_err("%s: not support, update libbpf\n", __func__);
> > > return -ENOTSUP;
> > > }
> > > ```
> >
> > both are v0.8 APIs
> >
> > > This will basically mean that while you dynamically linked with libbpf
> > > 0.8 you are in all likelihood not going to get proper BPF support.
> > > These changes up the version requirement to 1.0 and get rid entirely
> > > of the feature tests - so no runtime failing implementations. If the
> >
> > 100% supportive on upgrade and dropping feature checks. My point is
> > that you don't need those feature checks with v0.8+ requirement.
> >
> > The only difference between staying on v0.8+ vs going all the way to
> > v1.0+ would be that you have to keep libbpf_set_strict() call. In
> > v1.0+ it's a noop, so could be dropped.
> >
> > > build determines at build time libbpf 1.0+ isn't present then it still
> > > executes, switching from dynamic libbpf to the default static libbpf
> > > that is at 1.2. As mentioned in this thread, distributions like Debian
> > > use the default static linking of libbpf.
> > >
> >
> > oh, that's nice, good to know
> >
> > > I'm not keen to hold on to the feature tests for the complexity that
> > > they hold and their needlessly (as you can always statically link)
> > > broken at runtime behavior. We could but my opinion is, let's not :-)
> >
> > I've been consistently advocating for static linking with libbpf, so
> > 100% support this.
>
> Right, so I think we should move forward with these patches. We also
+1
jirka
> have had non-API changes to support libbpf 1.0+ like:
> https://lore.kernel.org/lkml/[email protected]/
> and I'm worried about the state of these with libbpf 0.8.
>
> Thanks,
> Ian
>
> > >
> > > Thanks,
> > > Ian
> > >
> > > > > Best regards,
> > > > > -Guilherme
> > > > >