On 09/04/19 09:06, Joel Fernandes wrote: > > > > It is actually true. > > > > But you need to make the distinction between a tracepoint > > and a trace event first. > > I know this distinction well. > > > What Valentin is talking about here is the *bare* > > tracepoint without any event associated with them like the one I added to > > the > > scheduler recently. These ones are not accessible via eBPF, unless something > > has changed since I last tried. > > Can this tracepoint be registered on with tracepoint_probe_register()? > Quickly looking at these new tracepoint, they can be otherwise how would they > even work right? If so, then eBPF can very well access it. Look at > __bpf_probe_register() and bpf_raw_tracepoint_open() which implement the > BPF_RAW_TRACEPOINT_OPEN.
Humm okay. I tried to use raw tracepoint with bcc but failed to attach. But maybe I missed something on the way it should be used. AFAICT it was missing the bits that I implemented in [1]. Maybe the method you mention is lower level than bcc. > > > The current infrastructure needs to be expanded to allow eBPF to attach > > these > > bare tracepoints. Something similar to what I have in [1] is needed - but > > instead of creating a new macro it needs to expand the current macro. [2] > > might > > give full context of when I was trying to come up with alternatives to using > > trace events. > > > > [1] > > https://github.com/qais-yousef/linux/commit/fb9fea29edb8af327e6b2bf3bc41469a8e66df8b > > [2] > > https://lore.kernel.org/lkml/20190415144945.tumeop4djyj45...@e107158-lin.cambridge.arm.com/ > > > As I was mentioning, tracepoints, not "trace events" can already be opened > directly with BPF. I don't see how these new tracepoints are different. > > I wonder if this distinction of "tracepoint" being non-ABI can be documented > somewhere. I would be happy to do that if there is a place for the same. I > really want some general "policy" in the kernel on where we draw a line in > the sand with respect to tracepoints and ABI :). > > For instance, perhaps VFS can also start having non-ABI tracepoints for the > benefit of people tracing the VFS. Good question. I did consider that but failed to come up with a place. AFAIU the history moved from tracepoints to trace events and now moving back to tracepoints. Something Steve is not very enthusiastic about. LPC is coming, sounds like a good venue to discuss this :-) Cheers -- Qais Yousef