Hi Steven, On 10/4/2021 10:46 PM, Steven Rostedt wrote: > On Mon, 4 Oct 2021 17:48:54 +0800 > Hou Tao <hotforest@xxxxxxxxx> wrote: > >> The main idea comes from patchset "writable contexts for bpf raw >> tracepoints" [1], but it only supports normal tracepoint with >> associated trace event under tracefs. Now we have one use case >> in which we add bare tracepoint in VFS layer, and update >> file::f_mode for specific files. The reason using bare tracepoint >> is that it doesn't form a ABI and we can change it freely. So >> add support for it in BPF. > Are the VFS maintainers against adding a trace event with just a pointer as > an interface? Not tried yet, but considering that VFS maintainer refused to have tracepoint in VFS layer, I'm not sure it is worth trying. > > That is, it only gives you a pointer to what is passed in, but does not > give you anything else to form any API against it. > This way, not only does BPF have access to this information, so do the > other tracers, through the new eprobe interface: Or in a opposite way can eprobe add support for bare tracepoint ? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/trace?id=7491e2c442781a1860181adb5ab472a52075f393 > > (I just realized we are missing updates to the Documentation directory). > > event probes allows one to attach to an existing trace event, and then > create a new trace event that can read through pointers. It uses the same > interface that kprobes has. > > Just adding trace events to VFS that only have pointers would allow all of > BPF, perf and ftrace access as eprobes could then get the data you are > looking for. > > -- Steve > .
