[PATCH v2 0/3] Assume libbpf 1.0+

[PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

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@google.com/
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@kernel.org/
This change goes further in removing logic that is now no longer
necessary.

v2. Rebase now that breakage fix patch is in linus/master.

Ian Rogers (3):
  tools build: Pass libbpf feature only if libbpf 1.0+
  perf build: Remove libbpf pre-1.0 feature tests
  perf bpf: Remove pre libbpf 1.0 conditional logic

 tools/build/feature/Makefile                  |  7 --
 .../feature/test-libbpf-bpf_map_create.c      |  8 ---
 .../test-libbpf-bpf_object__next_map.c        |  8 ---
 .../test-libbpf-bpf_object__next_program.c    |  8 ---
 .../build/feature/test-libbpf-bpf_prog_load.c |  9 ---
 .../test-libbpf-bpf_program__set_insns.c      |  8 ---
 .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ---
 .../build/feature/test-libbpf-btf__raw_data.c |  8 ---
 tools/build/feature/test-libbpf.c             |  4 ++
 tools/perf/Makefile.config                    | 39 +----------
 tools/perf/util/bpf-event.c                   | 66 -------------------
 tools/perf/util/bpf-loader.c                  | 18 -----
 tools/perf/util/bpf_counter.c                 | 18 -----
 13 files changed, 5 insertions(+), 204 deletions(-)
 delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c

-- 
2.39.0.314.g84b9a713c41-goog

[PATCH v2 1/3] tools build: Pass libbpf feature only if libbpf 1.0+

[Ian Rogers]

libbpf 1.0 represented a cleanup and stabilization of APIs. Simplify
development by only passing the feature test if libbpf 1.0 is
installed.

Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/build/feature/test-libbpf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/build/feature/test-libbpf.c b/tools/build/feature/test-libbpf.c
index a508756cf4cc..cd9989f52119 100644
--- a/tools/build/feature/test-libbpf.c
+++ b/tools/build/feature/test-libbpf.c
@@ -1,6 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <bpf/libbpf.h>
 
+#if !defined(LIBBPF_MAJOR_VERSION) || (LIBBPF_MAJOR_VERSION < 1)
+#error At least libbpf 1.0 is required for Linux tools.
+#endif
+
 int main(void)
 {
 	return bpf_object__open("test") ? 0 : -1;
-- 
2.39.0.314.g84b9a713c41-goog

[PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Ian Rogers]

The feature tests were necessary for libbpf pre-1.0, but as the libbpf
implies at least 1.0 we can remove these now.

Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/build/feature/Makefile                  |  7 ---
 .../feature/test-libbpf-bpf_map_create.c      |  8 ----
 .../test-libbpf-bpf_object__next_map.c        |  8 ----
 .../test-libbpf-bpf_object__next_program.c    |  8 ----
 .../build/feature/test-libbpf-bpf_prog_load.c |  9 ----
 .../test-libbpf-bpf_program__set_insns.c      |  8 ----
 .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ----
 .../build/feature/test-libbpf-btf__raw_data.c |  8 ----
 tools/perf/Makefile.config                    | 48 ++++---------------
 9 files changed, 10 insertions(+), 102 deletions(-)
 delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
 delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
 delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 690fe97be190..dc9323e01e42 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -58,13 +58,6 @@ FILES=                                          \
          test-lzma.bin                          \
          test-bpf.bin                           \
          test-libbpf.bin                        \
-         test-libbpf-btf__load_from_kernel_by_id.bin	\
-         test-libbpf-bpf_prog_load.bin          \
-         test-libbpf-bpf_map_create.bin		\
-         test-libbpf-bpf_object__next_program.bin \
-         test-libbpf-bpf_object__next_map.bin   \
-         test-libbpf-bpf_program__set_insns.bin	\
-         test-libbpf-btf__raw_data.bin          \
          test-get_cpuid.bin                     \
          test-sdt.bin                           \
          test-cxx.bin                           \
diff --git a/tools/build/feature/test-libbpf-bpf_map_create.c b/tools/build/feature/test-libbpf-bpf_map_create.c
deleted file mode 100644
index b9f550e332c8..000000000000
--- a/tools/build/feature/test-libbpf-bpf_map_create.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/bpf.h>
-
-int main(void)
-{
-	return bpf_map_create(0 /* map_type */, NULL /* map_name */, 0, /* key_size */,
-			      0 /* value_size */, 0 /* max_entries */, NULL /* opts */);
-}
diff --git a/tools/build/feature/test-libbpf-bpf_object__next_map.c b/tools/build/feature/test-libbpf-bpf_object__next_map.c
deleted file mode 100644
index 64adb519e97e..000000000000
--- a/tools/build/feature/test-libbpf-bpf_object__next_map.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/libbpf.h>
-
-int main(void)
-{
-	bpf_object__next_map(NULL /* obj */, NULL /* prev */);
-	return 0;
-}
diff --git a/tools/build/feature/test-libbpf-bpf_object__next_program.c b/tools/build/feature/test-libbpf-bpf_object__next_program.c
deleted file mode 100644
index 8bf4fd26b545..000000000000
--- a/tools/build/feature/test-libbpf-bpf_object__next_program.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/libbpf.h>
-
-int main(void)
-{
-	bpf_object__next_program(NULL /* obj */, NULL /* prev */);
-	return 0;
-}
diff --git a/tools/build/feature/test-libbpf-bpf_prog_load.c b/tools/build/feature/test-libbpf-bpf_prog_load.c
deleted file mode 100644
index 47f516d63ebc..000000000000
--- a/tools/build/feature/test-libbpf-bpf_prog_load.c
+++ /dev/null
@@ -1,9 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/bpf.h>
-
-int main(void)
-{
-	return bpf_prog_load(0 /* prog_type */, NULL /* prog_name */,
-			     NULL /* license */, NULL /* insns */,
-			     0 /* insn_cnt */, NULL /* opts */);
-}
diff --git a/tools/build/feature/test-libbpf-bpf_program__set_insns.c b/tools/build/feature/test-libbpf-bpf_program__set_insns.c
deleted file mode 100644
index f3b7f18c8f49..000000000000
--- a/tools/build/feature/test-libbpf-bpf_program__set_insns.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/libbpf.h>
-
-int main(void)
-{
-	bpf_program__set_insns(NULL /* prog */, NULL /* new_insns */, 0 /* new_insn_cnt */);
-	return 0;
-}
diff --git a/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c b/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
deleted file mode 100644
index a17647f7d5a4..000000000000
--- a/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/btf.h>
-
-int main(void)
-{
-	btf__load_from_kernel_by_id(20151128);
-	return 0;
-}
diff --git a/tools/build/feature/test-libbpf-btf__raw_data.c b/tools/build/feature/test-libbpf-btf__raw_data.c
deleted file mode 100644
index 57da31dd7581..000000000000
--- a/tools/build/feature/test-libbpf-btf__raw_data.c
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <bpf/btf.h>
-
-int main(void)
-{
-	btf__raw_data(NULL /* btf_ro */, NULL /* size */);
-	return 0;
-}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 5b8784675903..5ab7cac48c4a 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -565,54 +565,26 @@ ifndef NO_LIBELF
 
       # detecting libbpf without LIBBPF_DYNAMIC, so make VF=1 shows libbpf detection status
       $(call feature_check,libbpf)
+
+      # Feature test requires libbpf 1.0 so we can assume the following:
+      CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
+      CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
+      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
+      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
+      CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
+      CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
+      CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
+
       ifdef LIBBPF_DYNAMIC
         ifeq ($(feature-libbpf), 1)
           EXTLIBS += -lbpf
           $(call detected,CONFIG_LIBBPF_DYNAMIC)
-
-          $(call feature_check,libbpf-btf__load_from_kernel_by_id)
-          ifeq ($(feature-libbpf-btf__load_from_kernel_by_id), 1)
-            CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
-          endif
-          $(call feature_check,libbpf-bpf_prog_load)
-          ifeq ($(feature-libbpf-bpf_prog_load), 1)
-            CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
-          endif
-          $(call feature_check,libbpf-bpf_object__next_program)
-          ifeq ($(feature-libbpf-bpf_object__next_program), 1)
-            CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
-          endif
-          $(call feature_check,libbpf-bpf_object__next_map)
-          ifeq ($(feature-libbpf-bpf_object__next_map), 1)
-            CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
-          endif
-          $(call feature_check,libbpf-bpf_program__set_insns)
-          ifeq ($(feature-libbpf-bpf_program__set_insns), 1)
-            CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
-          else
-            dummy := $(error Error: libbpf devel library needs to be >= 0.8.0 to build with LIBBPF_DYNAMIC, update or build statically with the version that comes with the kernel sources);
-          endif
-          $(call feature_check,libbpf-btf__raw_data)
-          ifeq ($(feature-libbpf-btf__raw_data), 1)
-            CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
-          endif
-          $(call feature_check,libbpf-bpf_map_create)
-          ifeq ($(feature-libbpf-bpf_map_create), 1)
-            CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
-          endif
         else
           dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
         endif
       else
         # Libbpf will be built as a static library from tools/lib/bpf.
 	LIBBPF_STATIC := 1
-	CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
-        CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
-        CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
-        CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
-        CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
-        CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
-        CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
       endif
     endif
 
-- 
2.39.0.314.g84b9a713c41-goog

[PATCH v2 3/3] perf bpf: Remove pre libbpf 1.0 conditional logic

[Ian Rogers]

Tests are no longer applicable as libbpf 1.0 can be assumed.

Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/perf/Makefile.config    |  9 -----
 tools/perf/util/bpf-event.c   | 66 -----------------------------------
 tools/perf/util/bpf-loader.c  | 18 ----------
 tools/perf/util/bpf_counter.c | 18 ----------
 4 files changed, 111 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 5ab7cac48c4a..86ab83d48013 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -566,15 +566,6 @@ ifndef NO_LIBELF
       # detecting libbpf without LIBBPF_DYNAMIC, so make VF=1 shows libbpf detection status
       $(call feature_check,libbpf)
 
-      # Feature test requires libbpf 1.0 so we can assume the following:
-      CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
-      CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
-      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
-      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
-      CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
-      CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
-      CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
-
       ifdef LIBBPF_DYNAMIC
         ifeq ($(feature-libbpf), 1)
           EXTLIBS += -lbpf
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index cc7c1f90cf62..025f331b3867 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -22,72 +22,6 @@
 #include "record.h"
 #include "util/synthetic-events.h"
 
-#ifndef HAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
-struct btf *btf__load_from_kernel_by_id(__u32 id)
-{
-       struct btf *btf;
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-       int err = btf__get_from_id(id, &btf);
-#pragma GCC diagnostic pop
-
-       return err ? ERR_PTR(err) : btf;
-}
-#endif
-
-#ifndef HAVE_LIBBPF_BPF_PROG_LOAD
-LIBBPF_API int bpf_load_program(enum bpf_prog_type type,
-				const struct bpf_insn *insns, size_t insns_cnt,
-				const char *license, __u32 kern_version,
-				char *log_buf, size_t log_buf_sz);
-
-int bpf_prog_load(enum bpf_prog_type prog_type,
-		  const char *prog_name __maybe_unused,
-		  const char *license,
-		  const struct bpf_insn *insns, size_t insn_cnt,
-		  const struct bpf_prog_load_opts *opts)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-	return bpf_load_program(prog_type, insns, insn_cnt, license,
-				opts->kern_version, opts->log_buf, opts->log_size);
-#pragma GCC diagnostic pop
-}
-#endif
-
-#ifndef HAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
-struct bpf_program *
-bpf_object__next_program(const struct bpf_object *obj, struct bpf_program *prev)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-	return bpf_program__next(prev, obj);
-#pragma GCC diagnostic pop
-}
-#endif
-
-#ifndef HAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
-struct bpf_map *
-bpf_object__next_map(const struct bpf_object *obj, const struct bpf_map *prev)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-	return bpf_map__next(prev, obj);
-#pragma GCC diagnostic pop
-}
-#endif
-
-#ifndef HAVE_LIBBPF_BTF__RAW_DATA
-const void *
-btf__raw_data(const struct btf *btf_ro, __u32 *size)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-	return btf__get_raw_data(btf_ro, size);
-#pragma GCC diagnostic pop
-}
-#endif
-
 static int snprintf_hex(char *buf, size_t size, unsigned char *data, size_t len)
 {
 	int ret = 0;
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 6e9b06cf06ee..44cde27d6389 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -32,24 +32,6 @@
 
 #include <internal/xyarray.h>
 
-#ifndef HAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
-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;
-}
-#endif
-
 /* temporarily disable libbpf deprecation warnings */
 #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 
diff --git a/tools/perf/util/bpf_counter.c b/tools/perf/util/bpf_counter.c
index eeee899fcf34..aa78a15a6f0a 100644
--- a/tools/perf/util/bpf_counter.c
+++ b/tools/perf/util/bpf_counter.c
@@ -312,24 +312,6 @@ static bool bperf_attr_map_compatible(int attr_map_fd)
 		(map_info.value_size == sizeof(struct perf_event_attr_map_entry));
 }
 
-#ifndef HAVE_LIBBPF_BPF_MAP_CREATE
-LIBBPF_API int bpf_create_map(enum bpf_map_type map_type, int key_size,
-                              int value_size, int max_entries, __u32 map_flags);
-int
-bpf_map_create(enum bpf_map_type map_type,
-	       const char *map_name __maybe_unused,
-	       __u32 key_size,
-	       __u32 value_size,
-	       __u32 max_entries,
-	       const struct bpf_map_create_opts *opts __maybe_unused)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-	return bpf_create_map(map_type, key_size, value_size, max_entries, 0);
-#pragma GCC diagnostic pop
-}
-#endif
-
 static int bperf_lock_attr_map(struct target *target)
 {
 	char path[PATH_MAX];
-- 
2.39.0.314.g84b9a713c41-goog

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

On Sun, Jan 15, 2023 at 5:01 PM Ian Rogers <irogers@google.com> 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@google.com/
> 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@kernel.org/
> 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@kernel.org>
I believe we are waiting for package maintainer input.

Thanks,
Ian



> Ian Rogers (3):
>   tools build: Pass libbpf feature only if libbpf 1.0+
>   perf build: Remove libbpf pre-1.0 feature tests
>   perf bpf: Remove pre libbpf 1.0 conditional logic
>
>  tools/build/feature/Makefile                  |  7 --
>  .../feature/test-libbpf-bpf_map_create.c      |  8 ---
>  .../test-libbpf-bpf_object__next_map.c        |  8 ---
>  .../test-libbpf-bpf_object__next_program.c    |  8 ---
>  .../build/feature/test-libbpf-bpf_prog_load.c |  9 ---
>  .../test-libbpf-bpf_program__set_insns.c      |  8 ---
>  .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ---
>  .../build/feature/test-libbpf-btf__raw_data.c |  8 ---
>  tools/build/feature/test-libbpf.c             |  4 ++
>  tools/perf/Makefile.config                    | 39 +----------
>  tools/perf/util/bpf-event.c                   | 66 -------------------
>  tools/perf/util/bpf-loader.c                  | 18 -----
>  tools/perf/util/bpf_counter.c                 | 18 -----
>  13 files changed, 5 insertions(+), 204 deletions(-)
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c
>
> --
> 2.39.0.314.g84b9a713c41-goog
>

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Arnaldo Carvalho de Melo]

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@google.com> 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@google.com/
> > 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@kernel.org/
> > 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@kernel.org>
> 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Arnaldo Carvalho de Melo]

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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

On Thu, Jan 19, 2023 at 9:47 AM Arnaldo Carvalho de Melo
<acme@kernel.org> 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Jiri Olsa]

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@google.com> 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@google.com/
> > > 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@kernel.org/
> > > 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@kernel.org>
> > 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

On Thu, Jan 19, 2023 at 1:13 PM Jiri Olsa <olsajiri@gmail.com> 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@google.com> 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@google.com/
> > > > 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@kernel.org/
> > > > 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@kernel.org>
> > > 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Guilherme Amadio]

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@gmail.com> 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@google.com> 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@google.com/
> > > > > 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@kernel.org/
> > > > > 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@kernel.org>
> > > > 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Andrii Nakryiko]

On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > 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@kernel.org/
> > > > > > 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@kernel.org>
> > > > > 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
>

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > > 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@kernel.org/
> > > > > > > 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@kernel.org>
> > > > > > 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
> >

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Jiri Olsa]

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@gmail.com> 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@google.com> 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@google.com/
> > > > > 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@kernel.org/
> > > > > 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@kernel.org>
> > > > 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

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Justin Forbes]

On Fri, Mar 10, 2023 at 3:09 AM Jiri Olsa <olsajiri@gmail.com> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > 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@kernel.org/
> > > > > > 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@kernel.org>
> > > > > 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
>

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Andrii Nakryiko]

On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > > > 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@kernel.org/
> > > > > > > > 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@kernel.org>
> > > > > > > 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
> > >

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Ian Rogers]

On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > > > > 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@kernel.org/
> > > > > > > > > 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@kernel.org>
> > > > > > > > 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/20221103045437.163510-4-irogers@google.com/
and I'm worried about the state of these with libbpf 0.8.

Thanks,
Ian

> >
> > Thanks,
> > Ian
> >
> > > > Best regards,
> > > > -Guilherme
> > > >

Re: [PATCH v2 0/3] Assume libbpf 1.0+

[Jiri Olsa]

On Sat, Mar 11, 2023 at 05:00:01PM -0800, Ian Rogers wrote:
> On Fri, Mar 10, 2023 at 12:22 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Thu, Mar 9, 2023 at 7:26 PM Ian Rogers <irogers@google.com> wrote:
> > >
> > > On Thu, Mar 9, 2023 at 9:25 AM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 8, 2023 at 11:58 PM Guilherme Amadio <amadio@gentoo.org> 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@gmail.com> 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@google.com> 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@google.com/
> > > > > > > > > > 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@kernel.org/
> > > > > > > > > > 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@kernel.org>
> > > > > > > > > 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/20221103045437.163510-4-irogers@google.com/
> and I'm worried about the state of these with libbpf 0.8.
> 
> Thanks,
> Ian
> 
> > >
> > > Thanks,
> > > Ian
> > >
> > > > > Best regards,
> > > > > -Guilherme
> > > > >

Re: [PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Arnaldo Carvalho de Melo]

Em Sun, Jan 15, 2023 at 05:01:14PM -0800, Ian Rogers escreveu:
> The feature tests were necessary for libbpf pre-1.0, but as the libbpf
> implies at least 1.0 we can remove these now.

So I added this:

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 8b0bd3aa018ef166..b715cd4f43f4a014 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -580,7 +580,7 @@ ifndef NO_LIBELF
           EXTLIBS += -lbpf
           $(call detected,CONFIG_LIBBPF_DYNAMIC)
         else
-          dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
+          dummy := $(error Error: No libbpf devel library found or older than v1.0, please install/update libbpf-devel);
         endif
       else
         # Libbpf will be built as a static library from tools/lib/bpf.

To better reflect the failure reason:

⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-libbpf.make.output
test-libbpf.c:5:2: error: #error At least libbpf 1.0 is required for Linux tools.
    5 | #error At least libbpf 1.0 is required for Linux tools.
      |  ^~~~~
⬢[acme@toolbox perf-tools-next]$ rpm -q libbpf-devel
libbpf-devel-0.8.0-2.fc37.x86_64
⬢[acme@toolbox perf-tools-next]$

I'll see if I can make the build test conditional on libbpf being >= 1.0

- Arnaldo
 
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
>  tools/build/feature/Makefile                  |  7 ---
>  .../feature/test-libbpf-bpf_map_create.c      |  8 ----
>  .../test-libbpf-bpf_object__next_map.c        |  8 ----
>  .../test-libbpf-bpf_object__next_program.c    |  8 ----
>  .../build/feature/test-libbpf-bpf_prog_load.c |  9 ----
>  .../test-libbpf-bpf_program__set_insns.c      |  8 ----
>  .../test-libbpf-btf__load_from_kernel_by_id.c |  8 ----
>  .../build/feature/test-libbpf-btf__raw_data.c |  8 ----
>  tools/perf/Makefile.config                    | 48 ++++---------------
>  9 files changed, 10 insertions(+), 102 deletions(-)
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_map_create.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_map.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_object__next_program.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_prog_load.c
>  delete mode 100644 tools/build/feature/test-libbpf-bpf_program__set_insns.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
>  delete mode 100644 tools/build/feature/test-libbpf-btf__raw_data.c
> 
> diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
> index 690fe97be190..dc9323e01e42 100644
> --- a/tools/build/feature/Makefile
> +++ b/tools/build/feature/Makefile
> @@ -58,13 +58,6 @@ FILES=                                          \
>           test-lzma.bin                          \
>           test-bpf.bin                           \
>           test-libbpf.bin                        \
> -         test-libbpf-btf__load_from_kernel_by_id.bin	\
> -         test-libbpf-bpf_prog_load.bin          \
> -         test-libbpf-bpf_map_create.bin		\
> -         test-libbpf-bpf_object__next_program.bin \
> -         test-libbpf-bpf_object__next_map.bin   \
> -         test-libbpf-bpf_program__set_insns.bin	\
> -         test-libbpf-btf__raw_data.bin          \
>           test-get_cpuid.bin                     \
>           test-sdt.bin                           \
>           test-cxx.bin                           \
> diff --git a/tools/build/feature/test-libbpf-bpf_map_create.c b/tools/build/feature/test-libbpf-bpf_map_create.c
> deleted file mode 100644
> index b9f550e332c8..000000000000
> --- a/tools/build/feature/test-libbpf-bpf_map_create.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/bpf.h>
> -
> -int main(void)
> -{
> -	return bpf_map_create(0 /* map_type */, NULL /* map_name */, 0, /* key_size */,
> -			      0 /* value_size */, 0 /* max_entries */, NULL /* opts */);
> -}
> diff --git a/tools/build/feature/test-libbpf-bpf_object__next_map.c b/tools/build/feature/test-libbpf-bpf_object__next_map.c
> deleted file mode 100644
> index 64adb519e97e..000000000000
> --- a/tools/build/feature/test-libbpf-bpf_object__next_map.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/libbpf.h>
> -
> -int main(void)
> -{
> -	bpf_object__next_map(NULL /* obj */, NULL /* prev */);
> -	return 0;
> -}
> diff --git a/tools/build/feature/test-libbpf-bpf_object__next_program.c b/tools/build/feature/test-libbpf-bpf_object__next_program.c
> deleted file mode 100644
> index 8bf4fd26b545..000000000000
> --- a/tools/build/feature/test-libbpf-bpf_object__next_program.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/libbpf.h>
> -
> -int main(void)
> -{
> -	bpf_object__next_program(NULL /* obj */, NULL /* prev */);
> -	return 0;
> -}
> diff --git a/tools/build/feature/test-libbpf-bpf_prog_load.c b/tools/build/feature/test-libbpf-bpf_prog_load.c
> deleted file mode 100644
> index 47f516d63ebc..000000000000
> --- a/tools/build/feature/test-libbpf-bpf_prog_load.c
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/bpf.h>
> -
> -int main(void)
> -{
> -	return bpf_prog_load(0 /* prog_type */, NULL /* prog_name */,
> -			     NULL /* license */, NULL /* insns */,
> -			     0 /* insn_cnt */, NULL /* opts */);
> -}
> diff --git a/tools/build/feature/test-libbpf-bpf_program__set_insns.c b/tools/build/feature/test-libbpf-bpf_program__set_insns.c
> deleted file mode 100644
> index f3b7f18c8f49..000000000000
> --- a/tools/build/feature/test-libbpf-bpf_program__set_insns.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/libbpf.h>
> -
> -int main(void)
> -{
> -	bpf_program__set_insns(NULL /* prog */, NULL /* new_insns */, 0 /* new_insn_cnt */);
> -	return 0;
> -}
> diff --git a/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c b/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
> deleted file mode 100644
> index a17647f7d5a4..000000000000
> --- a/tools/build/feature/test-libbpf-btf__load_from_kernel_by_id.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/btf.h>
> -
> -int main(void)
> -{
> -	btf__load_from_kernel_by_id(20151128);
> -	return 0;
> -}
> diff --git a/tools/build/feature/test-libbpf-btf__raw_data.c b/tools/build/feature/test-libbpf-btf__raw_data.c
> deleted file mode 100644
> index 57da31dd7581..000000000000
> --- a/tools/build/feature/test-libbpf-btf__raw_data.c
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <bpf/btf.h>
> -
> -int main(void)
> -{
> -	btf__raw_data(NULL /* btf_ro */, NULL /* size */);
> -	return 0;
> -}
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 5b8784675903..5ab7cac48c4a 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -565,54 +565,26 @@ ifndef NO_LIBELF
>  
>        # detecting libbpf without LIBBPF_DYNAMIC, so make VF=1 shows libbpf detection status
>        $(call feature_check,libbpf)
> +
> +      # Feature test requires libbpf 1.0 so we can assume the following:
> +      CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
> +      CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
> +      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
> +      CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
> +      CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
> +      CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
> +      CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
> +
>        ifdef LIBBPF_DYNAMIC
>          ifeq ($(feature-libbpf), 1)
>            EXTLIBS += -lbpf
>            $(call detected,CONFIG_LIBBPF_DYNAMIC)
> -
> -          $(call feature_check,libbpf-btf__load_from_kernel_by_id)
> -          ifeq ($(feature-libbpf-btf__load_from_kernel_by_id), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
> -          endif
> -          $(call feature_check,libbpf-bpf_prog_load)
> -          ifeq ($(feature-libbpf-bpf_prog_load), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
> -          endif
> -          $(call feature_check,libbpf-bpf_object__next_program)
> -          ifeq ($(feature-libbpf-bpf_object__next_program), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
> -          endif
> -          $(call feature_check,libbpf-bpf_object__next_map)
> -          ifeq ($(feature-libbpf-bpf_object__next_map), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
> -          endif
> -          $(call feature_check,libbpf-bpf_program__set_insns)
> -          ifeq ($(feature-libbpf-bpf_program__set_insns), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
> -          else
> -            dummy := $(error Error: libbpf devel library needs to be >= 0.8.0 to build with LIBBPF_DYNAMIC, update or build statically with the version that comes with the kernel sources);
> -          endif
> -          $(call feature_check,libbpf-btf__raw_data)
> -          ifeq ($(feature-libbpf-btf__raw_data), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
> -          endif
> -          $(call feature_check,libbpf-bpf_map_create)
> -          ifeq ($(feature-libbpf-bpf_map_create), 1)
> -            CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
> -          endif
>          else
>            dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
>          endif
>        else
>          # Libbpf will be built as a static library from tools/lib/bpf.
>  	LIBBPF_STATIC := 1
> -	CFLAGS += -DHAVE_LIBBPF_BTF__LOAD_FROM_KERNEL_BY_ID
> -        CFLAGS += -DHAVE_LIBBPF_BPF_PROG_LOAD
> -        CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_PROGRAM
> -        CFLAGS += -DHAVE_LIBBPF_BPF_OBJECT__NEXT_MAP
> -        CFLAGS += -DHAVE_LIBBPF_BPF_PROGRAM__SET_INSNS
> -        CFLAGS += -DHAVE_LIBBPF_BTF__RAW_DATA
> -        CFLAGS += -DHAVE_LIBBPF_BPF_MAP_CREATE
>        endif
>      endif
>  
> -- 
> 2.39.0.314.g84b9a713c41-goog

-- 

- Arnaldo

Re: [PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Arnaldo Carvalho de Melo]

Em Mon, Mar 13, 2023 at 06:10:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Jan 15, 2023 at 05:01:14PM -0800, Ian Rogers escreveu:
> > The feature tests were necessary for libbpf pre-1.0, but as the libbpf
> > implies at least 1.0 we can remove these now.
> 
> So I added this:
> 
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 8b0bd3aa018ef166..b715cd4f43f4a014 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -580,7 +580,7 @@ ifndef NO_LIBELF
>            EXTLIBS += -lbpf
>            $(call detected,CONFIG_LIBBPF_DYNAMIC)
>          else
> -          dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
> +          dummy := $(error Error: No libbpf devel library found or older than v1.0, please install/update libbpf-devel);
>          endif
>        else
>          # Libbpf will be built as a static library from tools/lib/bpf.
> 
> To better reflect the failure reason:
> 
> ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-libbpf.make.output
> test-libbpf.c:5:2: error: #error At least libbpf 1.0 is required for Linux tools.
>     5 | #error At least libbpf 1.0 is required for Linux tools.
>       |  ^~~~~
> ⬢[acme@toolbox perf-tools-next]$ rpm -q libbpf-devel
> libbpf-devel-0.8.0-2.fc37.x86_64
> ⬢[acme@toolbox perf-tools-next]$
> 
> I'll see if I can make the build test conditional on libbpf being >= 1.0

I'm trying with this:

⬢[acme@toolbox libbpf]$ git log --oneline -1 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
9476dce6fe905a6b libbpf: remove deprecated low-level APIs
⬢[acme@toolbox libbpf]$ git tag --contains 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
v1.0.0
v1.0.1
v1.1.0
⬢[acme@toolbox libbpf]$

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 531324c3dab594e1..f866c58b916f4d7a 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -63,6 +63,7 @@ endif
 
 has = $(shell which $1 2>/dev/null)
 python_perf_so := $(shell $(MAKE) python_perf_target|grep "Target is:"|awk '{print $$3}')
+old_libbpf := $(shell grep -q LIBBPF_DEPRECATED /usr/include/bpf/bpf.h)
 
 # standard single make variable specified
 make_clean_all      := clean all
@@ -151,7 +152,9 @@ run += make_no_libaudit
 run += make_no_libbionic
 run += make_no_auxtrace
 run += make_no_libbpf
+ifneq ($(old_libbpf),)
 run += make_libbpf_dynamic
+endif
 run += make_no_libbpf_DEBUG
 run += make_no_libcrypto
 run += make_no_sdt

Re: [PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Ian Rogers]

On Mon, Mar 13, 2023 at 2:38 PM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> Em Mon, Mar 13, 2023 at 06:10:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Sun, Jan 15, 2023 at 05:01:14PM -0800, Ian Rogers escreveu:
> > > The feature tests were necessary for libbpf pre-1.0, but as the libbpf
> > > implies at least 1.0 we can remove these now.
> >
> > So I added this:
> >
> > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > index 8b0bd3aa018ef166..b715cd4f43f4a014 100644
> > --- a/tools/perf/Makefile.config
> > +++ b/tools/perf/Makefile.config
> > @@ -580,7 +580,7 @@ ifndef NO_LIBELF
> >            EXTLIBS += -lbpf
> >            $(call detected,CONFIG_LIBBPF_DYNAMIC)
> >          else
> > -          dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
> > +          dummy := $(error Error: No libbpf devel library found or older than v1.0, please install/update libbpf-devel);
> >          endif
> >        else
> >          # Libbpf will be built as a static library from tools/lib/bpf.
> >
> > To better reflect the failure reason:
> >
> > ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-libbpf.make.output
> > test-libbpf.c:5:2: error: #error At least libbpf 1.0 is required for Linux tools.
> >     5 | #error At least libbpf 1.0 is required for Linux tools.
> >       |  ^~~~~
> > ⬢[acme@toolbox perf-tools-next]$ rpm -q libbpf-devel
> > libbpf-devel-0.8.0-2.fc37.x86_64
> > ⬢[acme@toolbox perf-tools-next]$
> >
> > I'll see if I can make the build test conditional on libbpf being >= 1.0
>
> I'm trying with this:
>
> ⬢[acme@toolbox libbpf]$ git log --oneline -1 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> 9476dce6fe905a6b libbpf: remove deprecated low-level APIs
> ⬢[acme@toolbox libbpf]$ git tag --contains 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> v1.0.0
> v1.0.1
> v1.1.0
> ⬢[acme@toolbox libbpf]$
>
> diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> index 531324c3dab594e1..f866c58b916f4d7a 100644
> --- a/tools/perf/tests/make
> +++ b/tools/perf/tests/make
> @@ -63,6 +63,7 @@ endif
>
>  has = $(shell which $1 2>/dev/null)
>  python_perf_so := $(shell $(MAKE) python_perf_target|grep "Target is:"|awk '{print $$3}')
> +old_libbpf := $(shell grep -q LIBBPF_DEPRECATED /usr/include/bpf/bpf.h)

I think this could also be:
old_libbpf := $(shell grep MAJOR /usr/include/bpf/libbpf_version.h
2>&1 |grep -q  0)
Which may be a bit more intention revealing and future proof.

Thanks,
Ian

>  # standard single make variable specified
>  make_clean_all      := clean all
> @@ -151,7 +152,9 @@ run += make_no_libaudit
>  run += make_no_libbionic
>  run += make_no_auxtrace
>  run += make_no_libbpf
> +ifneq ($(old_libbpf),)
>  run += make_libbpf_dynamic
> +endif
>  run += make_no_libbpf_DEBUG
>  run += make_no_libcrypto
>  run += make_no_sdt

Re: [PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Ian Rogers]

On Mon, Mar 13, 2023 at 5:19 PM Ian Rogers <irogers@google.com> wrote:
>
> On Mon, Mar 13, 2023 at 2:38 PM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Mon, Mar 13, 2023 at 06:10:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Sun, Jan 15, 2023 at 05:01:14PM -0800, Ian Rogers escreveu:
> > > > The feature tests were necessary for libbpf pre-1.0, but as the libbpf
> > > > implies at least 1.0 we can remove these now.
> > >
> > > So I added this:
> > >
> > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > > index 8b0bd3aa018ef166..b715cd4f43f4a014 100644
> > > --- a/tools/perf/Makefile.config
> > > +++ b/tools/perf/Makefile.config
> > > @@ -580,7 +580,7 @@ ifndef NO_LIBELF
> > >            EXTLIBS += -lbpf
> > >            $(call detected,CONFIG_LIBBPF_DYNAMIC)
> > >          else
> > > -          dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
> > > +          dummy := $(error Error: No libbpf devel library found or older than v1.0, please install/update libbpf-devel);
> > >          endif
> > >        else
> > >          # Libbpf will be built as a static library from tools/lib/bpf.
> > >
> > > To better reflect the failure reason:
> > >
> > > ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-libbpf.make.output
> > > test-libbpf.c:5:2: error: #error At least libbpf 1.0 is required for Linux tools.
> > >     5 | #error At least libbpf 1.0 is required for Linux tools.
> > >       |  ^~~~~
> > > ⬢[acme@toolbox perf-tools-next]$ rpm -q libbpf-devel
> > > libbpf-devel-0.8.0-2.fc37.x86_64
> > > ⬢[acme@toolbox perf-tools-next]$
> > >
> > > I'll see if I can make the build test conditional on libbpf being >= 1.0
> >
> > I'm trying with this:
> >
> > ⬢[acme@toolbox libbpf]$ git log --oneline -1 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> > 9476dce6fe905a6b libbpf: remove deprecated low-level APIs
> > ⬢[acme@toolbox libbpf]$ git tag --contains 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> > v1.0.0
> > v1.0.1
> > v1.1.0
> > ⬢[acme@toolbox libbpf]$
> >
> > diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> > index 531324c3dab594e1..f866c58b916f4d7a 100644
> > --- a/tools/perf/tests/make
> > +++ b/tools/perf/tests/make
> > @@ -63,6 +63,7 @@ endif
> >
> >  has = $(shell which $1 2>/dev/null)
> >  python_perf_so := $(shell $(MAKE) python_perf_target|grep "Target is:"|awk '{print $$3}')
> > +old_libbpf := $(shell grep -q LIBBPF_DEPRECATED /usr/include/bpf/bpf.h)
>
> I think this could also be:
> old_libbpf := $(shell grep MAJOR /usr/include/bpf/libbpf_version.h
> 2>&1 |grep -q  0)
> Which may be a bit more intention revealing and future proof.
>
> Thanks,
> Ian

To avoid /usr/include assumptions, there's also:
old_libbpf := $(shell echo "#include <bpf/libbpf.h>" | $(CC) -E -dM -x
c -|grep "define LIBBPF_MAJOR_VERSION"|grep -q 0)
:-)

Ian

> >  # standard single make variable specified
> >  make_clean_all      := clean all
> > @@ -151,7 +152,9 @@ run += make_no_libaudit
> >  run += make_no_libbionic
> >  run += make_no_auxtrace
> >  run += make_no_libbpf
> > +ifneq ($(old_libbpf),)
> >  run += make_libbpf_dynamic
> > +endif
> >  run += make_no_libbpf_DEBUG
> >  run += make_no_libcrypto
> >  run += make_no_sdt

Re: [PATCH v2 2/3] perf build: Remove libbpf pre-1.0 feature tests

[Arnaldo Carvalho de Melo]

Em Mon, Mar 13, 2023 at 05:19:45PM -0700, Ian Rogers escreveu:
> On Mon, Mar 13, 2023 at 2:38 PM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Mon, Mar 13, 2023 at 06:10:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Sun, Jan 15, 2023 at 05:01:14PM -0800, Ian Rogers escreveu:
> > > > The feature tests were necessary for libbpf pre-1.0, but as the libbpf
> > > > implies at least 1.0 we can remove these now.
> > >
> > > So I added this:
> > >
> > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > > index 8b0bd3aa018ef166..b715cd4f43f4a014 100644
> > > --- a/tools/perf/Makefile.config
> > > +++ b/tools/perf/Makefile.config
> > > @@ -580,7 +580,7 @@ ifndef NO_LIBELF
> > >            EXTLIBS += -lbpf
> > >            $(call detected,CONFIG_LIBBPF_DYNAMIC)
> > >          else
> > > -          dummy := $(error Error: No libbpf devel library found, please install libbpf-devel);
> > > +          dummy := $(error Error: No libbpf devel library found or older than v1.0, please install/update libbpf-devel);
> > >          endif
> > >        else
> > >          # Libbpf will be built as a static library from tools/lib/bpf.
> > >
> > > To better reflect the failure reason:
> > >
> > > ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-libbpf.make.output
> > > test-libbpf.c:5:2: error: #error At least libbpf 1.0 is required for Linux tools.
> > >     5 | #error At least libbpf 1.0 is required for Linux tools.
> > >       |  ^~~~~
> > > ⬢[acme@toolbox perf-tools-next]$ rpm -q libbpf-devel
> > > libbpf-devel-0.8.0-2.fc37.x86_64
> > > ⬢[acme@toolbox perf-tools-next]$
> > >
> > > I'll see if I can make the build test conditional on libbpf being >= 1.0
> >
> > I'm trying with this:
> >
> > ⬢[acme@toolbox libbpf]$ git log --oneline -1 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> > 9476dce6fe905a6b libbpf: remove deprecated low-level APIs
> > ⬢[acme@toolbox libbpf]$ git tag --contains 9476dce6fe905a6bf1d4c483f7b2b8575c4ffb2d
> > v1.0.0
> > v1.0.1
> > v1.1.0
> > ⬢[acme@toolbox libbpf]$
> >
> > diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> > index 531324c3dab594e1..f866c58b916f4d7a 100644
> > --- a/tools/perf/tests/make
> > +++ b/tools/perf/tests/make
> > @@ -63,6 +63,7 @@ endif
> >
> >  has = $(shell which $1 2>/dev/null)
> >  python_perf_so := $(shell $(MAKE) python_perf_target|grep "Target is:"|awk '{print $$3}')
> > +old_libbpf := $(shell grep -q LIBBPF_DEPRECATED /usr/include/bpf/bpf.h)
> 
> I think this could also be:
> old_libbpf := $(shell grep MAJOR /usr/include/bpf/libbpf_version.h
> 2>&1 |grep -q  0)
> Which may be a bit more intention revealing and future proof.

Thanks, I used:

old_libbpf := $(shell echo "#include <bpf/libbpf.h>" | $(CC) -E -dM -x c -| egrep -q "define[[:space:]]+LIBBPF_MAJOR_VERSION[[:space:]]+0{1}")

- Arnaldo