On Tue, 1 Aug 2023 15:21:59 -0700 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Aug 1, 2023 at 8:18 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > On Mon, 31 Jul 2023 19:24:25 -0700 > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > On Mon, Jul 31, 2023 at 6:15 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > > > On Mon, 31 Jul 2023 14:59:47 -0700 > > > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > > > Assuming that is addressed. How do we merge the series? > > > > > The first 3 patches have serious conflicts with bpf trees. > > > > > > > > > > Maybe send the first 3 with extra selftest for above recursion > > > > > targeting bpf-next then we can have a merge commit that Steven can pull > > > > > into tracing? > > > > > > > > Would it be possible to do this by basing it off of one of Linus's tags, > > > > and doing the merge and conflict resolution in your tree before it gets to > > > > Linus? > > > > > > > > That way we can pull in that clean branch without having to pull in > > > > anything else from BPF. I believe Linus prefers this over having tracing > > > > having extra changes from BPF that are not yet in his tree. We only need > > > > these particular changes, we shouldn't be pulling in anything specific for > > > > BPF, as I believe that will cause issues on Linus's side. > > > > > > We can try, but I suspect git tricks won't do it. > > > Masami's changes depend on patches for kernel/bpf/btf.c that > > > are already in bpf-next, so git would have to follow all commits > > > that touch this file. > > > > This point is strange. I'm working on probe/fixes which is based on > > v6.5-rc3, so any bpf-next change should not be involved. Can you recheck > > this point? > > > > > I don't think git is smart enough to > > > thread the needle and split the commit into files. If one commit touches > > > btf.c and something else that whole commit becomes a dependency > > > that pulls another commit with all files touched by > > > the previous commit and so on. > > > > As far as I understand Steve's method, we will have an intermediate branch > > on bpf or probe tree, like > > > > linus(some common commit) ---- probes/btf-find-api > > > > and merge it to both bpf-next and probes/for-next branch > > > > +----------------------bpf-next --- (merge bpf patches) > > / / merge > > common -/\ probes/btf-find-api -/-\ > > \ \ merge > > +----------------------probes/for-next --- (merge probe patches) > > > > Thus, we can merge both for-next branches at next merge window without > > any issue. (But, yes, this is not simple, and needs maxium care) > > Sounds like the path of least resistance is to keep the changes > in kernel/trace and consolidate with kernel/bpf/btf.c after the next > merge window. OK, sounds good to me. I will only expose the bpf_find_btf_id() then. Thank you, -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
