On 1/22/25 6:56 AM, Steven Rostedt wrote:

On Wed, 22 Jan 2025 01:39:42 -0800
Breno Leitao [off-list ref] wrote:

quoted

Right, DECLARE_TRACE would solve my current problem, but, a056a5bed7fa
("sched/debug: Export the newly added tracepoints") says "BPF doesn't
have infrastructure to access these bare tracepoints either.".

Does BPF know how to attach to this bare tracepointers now?

On the other side, it seems real tracepoints is getting more pervasive?
So, this current approach might be OK also?

	https://lore.kernel.org/bpf/20250118033723.GV1977892@ZenIV/T/#m4c2fb2d904e839b34800daf8578dff0b9abd69a0 (local)

Thanks for the pointer. I didn't know this discussion was going on. I just
asked to attend if this gets accepted. I'm only a 6 hour drive from
Montreal anyway.

quoted

quoted

You can see its use in include/trace/events/sched.h

I suppose I need to export the tracepointer with
EXPORT_TRACEPOINT_SYMBOL_GPL(), right?

For modules to use them directly, yes. But there's other ways too.

quoted

I am trying to hack something as the following, but, I struggled to hook
BPF into it.

Maybe you can use the iterator to search for the tracepoint.

#include <linux/tracepoint.h>

static void fct(struct tracepoint *tp, void *priv)
{
	if (!tp->name || strcmp(tp->name, "<tracepoint_name>") != 0)
		return 0;

	// attach to tracepoint tp
}

[..]
	for_each_kernel_tracepoint(fct, NULL);

This is how LTTng hooks to tracepoints.

The LTTng approach in the above needs a kernel module to enable and disable
the tracepoint and this is not a bpf-way to handle tracepoints.

So for bpf, we need a new UAPI to pass <tracepoint_name> from user
space to the kernel to attach to tracepoint tp since <tracepont_name> is not
available in trace_fs.

What is the criteria for a tracepoint to be a normal tp or a bare tp?

-- Steve