> > > > > > Can we achieve the same/similar performance with sys_bpf(BPF_PROG_RUN)? > > > > > > > I think so, the tough part is how do you let the user-space know which > > program is attached to run? In the current code this is done by the BPF > > program attaching to the event via perf and we run the one there if > > any when data is emitted out via write calls. > > > > I would want to make sure that operators can decide where the user-space > > data goes (perf/ftrace/eBPF) after the code has been written. With the > > current code this is done via the tracepoint callbacks that perf/ftrace > > hook up when operators enable recording via perf, tracefs, libbpf, etc. > > > > We have managed code (C#/Java) where we cannot utilize stubs or traps > > easily due to code movement. So we are limited in how we can approach > > this problem. Having the interface be mmap/write has enabled this > > for us, since it's easy to interact with in most languages and gives us > > lifetime management of the trace objects between user-space and the > > kernel. > > Then you should probably invest into making USDT work inside > java applications instead of reinventing the wheel. > > As an alternative you can do a dummy write or any other syscall > and attach bpf on the kernel side. > No kernel changes are necessary. We only want syscall/tracing overheads for the specific events that are hooked. I don't see how we could hook up a dummy write that is unique per-event without having a way to know when the event is being traced. Thanks, -Beau
