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

[John Ogness <john.ogness@linutronix.de>]

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.

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).

If you want the rv tool to provide some basic stdout data from the
monitors, I am fine with that. That is certainly useful to easily see if
a violation occurred.

But for serious investigations, I really just need the tool to
start/stop the monitor and tell me how to grab the violation events.

> I'm trying to keep this use-case in mind though.

Thank you.

> I assume you aren't interested in the "event" events (transitions in
> the model), those are useful when developing models, at least in
> DA. And those do not trigger a reaction (stdout only for now).

As an RV-monitor _user_ I am not interested in RV state transitions. I
do not know if RV-monitor _developers_ might need that. I would think it
would be useful when debugging RV-monitor false-positives or missed
violations.

@namcao: Maybe you could chime in if you want the transitions as events.

John