On Wed, Jun 01, 2022 at 10:39:08AM -0700, Andrii Nakryiko wrote: > On Tue, May 24, 2022 at 1:28 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > On Mon, May 23, 2022 at 03:43:10PM -0700, Andrii Nakryiko wrote: > > > On Mon, May 23, 2022 at 12:49 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > > > > > On Sat, May 21, 2022 at 02:44:05PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > Em Fri, May 20, 2022 at 02:46:49PM -0700, Andrii Nakryiko escreveu: > > > > > > On Thu, May 19, 2022 at 4:03 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > > > > On Wed, May 18, 2022 at 11:46:44AM +0200, Jiri Olsa wrote: > > > > > > > > On Tue, May 17, 2022 at 03:02:53PM -0700, Andrii Nakryiko wrote: > > > > > > > > > Jiri, libbpf v0.8 is out, can you please re-send your perf patches? > > > > > > > > > > > > > yep, just made new fedora package.. will resend the perf changes soon > > > > > > > > > > > > fedora package is on the way, but I'll need perf/core to merge > > > > > > > the bpf_program__set_insns change.. Arnaldo, any idea when this > > > > > > > could happen? > > > > > > > > > > > Can we land these patches through bpf-next to avoid such complicated > > > > > > cross-tree dependencies? As I started removing libbpf APIs I also > > > > > > noticed that perf is still using few other deprecated APIs: > > > > > > - bpf_map__next; > > > > > > - bpf_program__next; > > > > > > - bpf_load_program; > > > > > > - btf__get_from_id; > > > > > > > > these were added just to bypass the time window when they were not > > > > available in the package, so can be removed now (in the patch below) > > > > > > > > > > > > > > > It's trivial to fix up, but doing it across few trees will delay > > > > > > libbpf work as well. > > > > > > > > > > > So let's land this through bpf-next, if Arnaldo doesn't mind? > > > > > > > > > > Yeah, that should be ok, the only consideration is that I'm submitting > > > > > this today to Linus: > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf/urgent&id=0ae065a5d265bc5ada13e350015458e0c5e5c351 > > > > > > > > > > To address this: > > > > > > > > > > https://lore.kernel.org/linux-perf-users/f0add43b-3de5-20c5-22c4-70aff4af959f@xxxxxxxxxxxx/ > > > > > > > > ok, we can do that via bpf-next, but of course there's a problem ;-) > > > > > > > > perf/core already has dependency commit [1] > > > > > > > > so either we wait for perf/core and bpf-next/master to sync or: > > > > > > > > - perf/core reverts [1] and > > > > - bpf-next/master takes [1] and the rest > > > > > > > > I have the changes ready if you guys are ok with that > > > > > > So, if I understand correctly, with merge window open bpf-next/master > > > will get code from perf/core soon when we merge tip back in. So we can > > > wait for that to happen and not revert anything. > > > > > > So please add the below patch to your series and resend once tip is > > > merged into bpf-next? Thanks! > > > > ok > > Hm.. Ok, so I don't see your patches in tip yet. I see them in > perf/core only. Which means things won't happen naturally soon. How > should we proceed? I'm sitting on a pile of patches removing a lot of > code from libbpf and I'd rather get it out soon, but I can't because > of them breaking perf in bpf-next without Jiri's changes. sorry it's merged in linus master, Arnaldo no longer goes through tip tree > > Arnaldo, what's your suggestion? Can we land remaining Jiri's patches > into perf/core and then you can create a tag for us to merge into > bpf-next, so that we avoid any conflicts later? Would that work? I > think we did something like that with other trees (e.g., RCU), when we > had dependencies like this before. either way is fine for me.. I just rebased those changes on top of perf/core jirka
