Re: [PATCH bpf-next] perf: mute libbpf API deprecations temporarily

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 2, 2021 at 4:46 PM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote:
>
> Libbpf development version was bumped to 0.7 in c93faaaf2f67
> ("libbpf: Deprecate bpf_prog_load_xattr() API"), activating a bunch of
> previously scheduled deprecations. Most APIs are pretty straightforward
> to replace with newer APIs, but perf has a complicated mixed setup with
> libbpf used both as static and shared configurations, which makes it
> non-trivial to migrate the APIs.
>
> Further, bpf_program__set_prep() needs more involved refactoring, which
> will require help from Arnaldo and/or Jiri.
>
> So for now, mute deprecation warnings and work on migrating perf off of
> deprecated APIs separately with the input from owners of the perf tool.
>
> Fixes: c93faaaf2f67 ("libbpf: Deprecate bpf_prog_load_xattr() API")
> Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
> ---

Stephen,

This patch (when applied to bpf-next) should fix the build failure you
reported in your recent "linux-next: build failure after merge of the
bpf-next tree" email (that I didn't get directly, but thankfully
Alexei forwarded to me). Can you please also cc bpf@vger.kernel.orgfor
future bpf-next tree issues, as that's a more directly related mailing
list (ideally also cc me at andrii@xxxxxxxxxx directly so that we
don't rely on Gmail not dropping the email, I've, unfortunately, had
multiple problems with this recently). Thanks for understanding!

Arnaldo, Jiri,

Getting rid of most deprecations is pretty trivial, if not for the
hybrid static/dynamic setup. Please advise on the path forward. Do I
do __weak re-definitions of new APIs and switch the source code to new
variants?

As for bpf_program__set_prep(), assuming it's used to do program
cloning, bpf_program__insns() is a more straightforward and cleaner
way to do it now. But the logic seems to be more involved, so I'd like
you guys to do this conversion, if that's not too much trouble.

Regardless, let's work together to clean up perf's use of deprecated
APIs. Thanks!

>  tools/perf/tests/bpf.c       | 4 ++++
>  tools/perf/util/bpf-loader.c | 3 +++
>  2 files changed, 7 insertions(+)
>
> diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
> index 2bf146e49ce8..c52bf10f746e 100644
> --- a/tools/perf/tests/bpf.c
> +++ b/tools/perf/tests/bpf.c
> @@ -312,9 +312,13 @@ static int check_env(void)
>                 return err;
>         }
>
> +/* temporarily disable libbpf deprecation warnings */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>         err = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
>                                sizeof(insns) / sizeof(insns[0]),
>                                license, kver_int, NULL, 0);
> +#pragma GCC diagnostic pop
>         if (err < 0) {
>                 pr_err("Missing basic BPF support, skip this test: %s\n",
>                        strerror(errno));
> diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
> index fbb3c4057c30..528aeb0ab79d 100644
> --- a/tools/perf/util/bpf-loader.c
> +++ b/tools/perf/util/bpf-loader.c
> @@ -29,6 +29,9 @@
>
>  #include <internal/xyarray.h>
>
> +/* temporarily disable libbpf deprecation warnings */
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +
>  static int libbpf_perf_print(enum libbpf_print_level level __attribute__((unused)),
>                               const char *fmt, va_list args)
>  {
> --
> 2.30.2
>



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux