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 You mean other patches that Masami has sent are in the bpf tree already and these are on top of them? -- Steve > that touch this file. 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. > tbh for this set, the easiest for everyone, is to land the whole thing > through bpf-next, since there are no conflicts on fprobe side.
