linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Dave Marchevsky <davemarchevsky@fb.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	bpf <bpf@vger.kernel.org>,
	"linux-perf-use." <linux-perf-users@vger.kernel.org>,
	"Song Liu" <songliubraving@fb.com>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>
Subject: Re: [PATCH v2 bpf-next 4/4] libbpf: deprecate bpf_program__get_prog_info_linear
Date: Fri, 22 Oct 2021 12:26:04 -0700	[thread overview]
Message-ID: <CAEf4BzaGH63-kaM40ifCWBLncEn7tfJcKxGdVKOR0_jcdpeX1g@mail.gmail.com> (raw)
In-Reply-To: <d3de589a-21f3-7a0d-59de-126d3c70fba1@fb.com>

On Fri, Oct 22, 2021 at 12:18 PM Dave Marchevsky <davemarchevsky@fb.com> wrote:
>
> On 10/20/21 5:01 PM, Toke Høiland-Jørgensen wrote:
> > Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> >
> >> On Mon, Oct 11, 2021 at 1:20 AM Dave Marchevsky <davemarchevsky@fb.com> wrote:
> >>>
> >>> As part of the road to libbpf 1.0, and discussed in libbpf issue tracker
> >>> [0], bpf_program__get_prog_info_linear and its associated structs and
> >>> helper functions should be deprecated. The functionality is too specific
> >>> to the needs of 'perf', and there's little/no out-of-tree usage to
> >>> preclude introduction of a more general helper in the future.
> >>>
> >>> [0] Closes: https://github.com/libbpf/libbpf/issues/313
> >>
> >> styling nit: don't know if it's described anywhere or not, but when
> >> people do references like this, they use 2 spaces of indentation. No
> >> idea how it came to be, but that's what I did for a while and see
> >> others doing the same.
> >>
> >>>
> >>> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> >>> ---
>
> [...]
>
> >> we can actually deprecate all this starting from v0.6, because perf is
> >> building libbpf statically, so no worries about releases (also there
> >> are no replacement APIs we have to wait full release for)
> >
> > Just FYI, we're also using this in libxdp, and that does link
> > dynamically to libbpf. It's not an issue to move away from it[0], but
> > perf is not the only user :)
> >
> > -Toke
> >
> > [0] Track that here: https://github.com/xdp-project/xdp-tools/issues/127
> >
>
> I submitted a PR to migrate the xdp-tools usage as well. Strange that
> this didn't show up in an "all github" search.
>
> Andrii, should the DEPRECATED_SINCE stay at 0.7 in light of this?

There is no replacement API that we need to wait to go through full
libbpf release, so no, it can stay as is.

      parent reply	other threads:[~2021-10-22 19:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11  8:20 [PATCH v2 bpf-next 0/4] libbpf: deprecate bpf_program__get_prog_info_linear Dave Marchevsky
2021-10-11  8:20 ` [PATCH v2 bpf-next 1/4] libbpf: migrate internal use of bpf_program__get_prog_info_linear Dave Marchevsky
2021-10-20 17:36   ` Andrii Nakryiko
2021-10-11  8:20 ` [PATCH v2 bpf-next 2/4] bpftool: use bpf_obj_get_info_by_fd directly Dave Marchevsky
2021-10-20 17:37   ` Andrii Nakryiko
2021-10-20 22:15     ` Quentin Monnet
2021-10-11  8:20 ` [PATCH v2 bpf-next 3/4] perf: pull in bpf_program__get_prog_info_linear Dave Marchevsky
2021-10-20 17:37   ` Andrii Nakryiko
     [not found]     ` <5080FF1F-8E7A-4AF7-AD7E-7349E58CFEDB@fb.com>
2021-10-31 17:13       ` Arnaldo Carvalho de Melo
2021-10-11  8:20 ` [PATCH v2 bpf-next 4/4] libbpf: deprecate bpf_program__get_prog_info_linear Dave Marchevsky
2021-10-20 17:37   ` Andrii Nakryiko
2021-10-20 21:01     ` Toke Høiland-Jørgensen
     [not found]       ` <d3de589a-21f3-7a0d-59de-126d3c70fba1@fb.com>
2021-10-22 19:26         ` Andrii Nakryiko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEf4BzaGH63-kaM40ifCWBLncEn7tfJcKxGdVKOR0_jcdpeX1g@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davemarchevsky@fb.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).