On Fri, 4 Oct 2024 10:19:36 -0400 Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > The eBPF people want to leverage this. When I last discussed this with > eBPF maintainers, they were open to adapt eBPF after this infrastructure > series is merged. Based on this eBPF attempt from 2022: > > https://lore.kernel.org/lkml/c323bce9-a04e-b1c3-580a-783fde259d60@xxxxxx/ Sorry, I wasn't part of that discussion. > > The sframe code is just getting in shape (2024), but is far from being ready. > > Everyone appears to be waiting for this infrastructure work to go in > before they can build on top. Once this infrastructure is available, > multiple groups can start working on introducing use of this into their > own code in parallel. > > Four years into this effort, and this is the first time we're told we need > to adapt in-tree tracers to handle the page faults before this can go in. > > Could you please stop moving the goal posts ? I don't think I'm moving the goal posts. I was mentioning to show an in-tree user. If BPF wants this, I'm all for it. The only thing I saw was a generalization in the cover letter about perf, bpf and ftrace using faultible tracepoints. I just wanted to see a path for that happening. -- Steve
