On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@xxxxxxxxxx> 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 <olsajiri@xxxxxxxxx> 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 <irogers@xxxxxxxxxx> 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/20230106151320.619514-1-irogers@xxxxxxxxxx/
> > > > > > 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/Y71+eh00Ju7WeEFX@xxxxxxxxxx/
> > > > > > 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 <jolsa@xxxxxxxxxx>
> > > > > 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@xxxxxxxxxxxxxx/
> > 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
>
