Re: [PATCH v2 10/15] tools/rv: Add BPF monitors

[Gabriele Monaco <gmonaco@redhat.com>]

On Mon, 2026-10-19 at 11:16 +0206, John Ogness wrote:
> On 2026-10-19, Gabriele Monaco <gmonaco@redhat.com> wrote:
> > > > We are missing stack traces (which I'd optionally add only on errors)
> > > > and perhaps other events (e.g. the -e in either tool if you aren't
> > > > only interested in errors/events of the monitor).
> > > 
> > > I don't see the point of reinventing tools that already do the job
> > > well. I do not mind if developers want to create their own tools that
> > > provide some small subset of existing features. But I am concerned
> > > about removing the in-kernel RV support for ftrace and perf.
> > 
> > That's valid too. We'd need at least the rv tool to start/stop
> > monitors in addition to ftrace/perf. Kind of what you already do now
> > with sysfs.
> 
> I do not expect the rv tool to start/stop ftrace/perf. Nor would I
> consider that useful. When I am using ftrace/perf, I am interested in
> additionally related events. The rv tool can not know what what else I
> need and I do not want the rv tool to become a wrapper for ftrace/perf.

Yeah of course, I meant more that you need to call both tools (start the monitor
/and/ the tracing).

At most I'd have a -e flag in rv (just like rtla has, mirroring trace-cmd
functionality).
But you're right, it's best if the other tools can do that first.

> 
> I would use the rv tool only to start the monitor. It would be enough if
> the tool would report the bpf_trace:bpf_trace_printk globs that are
> needed for the various possible violations. Then, with the monitor
> started, I would start ftrace/perf for my own investigations (also
> capturing any violation events).
> 

That's an interesting idea actually.

Thanks,
Gabriele