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.