On Wed, Apr 23, 2025 at 11:51 AM Steven Rostedt <[email protected]> wrote: > > On Wed, 23 Apr 2025 11:21:25 -0700 > Andrii Nakryiko <[email protected]> wrote: > > > The part about accessing only from code within the kernel isn't true. > > Can we please drop that? BPF program can be attached to these bare > > tracepoints just fine without tracefs (so-called BPF raw tracepoint > > program types). > > Is it possible to see a list of these tracepoints from user space? If not, > then it's only available via the kernel. Sure BPF and even trace probes can > attach to them. Just like attaching to functions. The point is, they are > not exposed directly to user space. User space only knows about it if the > user has access to the kernel. > > Unless BPF does expose what's avaliable, does it? >
BPF by itself doesn't have any API to list tracepoints, so in that sense, no, BPF doesn't expose *the list* of those tracepoints. But the same can be said about kprobes or normal tracepoints. But it is allowed to attempt to attach to those tracepoints by just specifying their name as a string. I guess I'm confused about what "accessing only from code within the kernel" means. In my mind BPF isn't really "code within the kernel", but we are getting into the philosophical area now :) I just wanted to point out that this is consumable/attachable with BPF just like any other tracepoint, so it's not just kernel/module code that can attach to them. > > > > But I don't have an objection to the change itself, given all of them > > currently do have _tp suffix except a few that we have in BPF > > selftests's module, just as Jiri mentioned. > > > > Acked-by: Andrii Nakryiko <[email protected]> > > Thanks, > > -- Steve
