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

[Gabriele Monaco <gmonaco@redhat.com>]

On Sat, 2026-10-17 at 17:23 +0206, John Ogness wrote:
> On 2026-10-17, Gabriele Monaco <gmonaco@redhat.com> wrote:
> > > I am still not clear how the rv tool will replace the existing
> > > in-kernel implementation. Right now violations call printk(), which
> > > conveniently show up in kernel logs and consoles. More importantly,
> > > there are the rtapp violation events, which makes it very easy to use
> > > ftrace and perf features to record traces, take actions, generate
> > > statistics, and dump backtraces on violations.
> > 
> > The plan is to keep everything you'd now do with perf/ftrace as plain
> > stdout of the RV tool. Right now you can see the same ftrace output
> > using rv mon <monitor> -t for in-kernel monitors (only deterministic
> > automata).
> 
> IMHO it would be a pity to lose support for ftrace/perf. I use these
> tools extensively for my daily work evaluating real-time systems. Having
> the rtapp RVmon integrated allows me to easily and naturally extend my
> workflow to include rtapp violations. Plain stdout is hardly a
> replacement for trace recordings that can be imported into existing
> visualization and analysis tools.

Yeah that's a good point. And the trace-printk can only improve this to some
extent. Thought that alone can get you stack traces for free.

I think no matter what we choose now, having extensible reactors allows to
easily add new violation actions down the road, if we see it necessary.

> > 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'm trying to keep this use-case in mind though.

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

Thanks,
Gabriele