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

On 2026-10-17, Gabriele Monaco [off-list ref] wrote:

quoted

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.

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.

quoted

Is it planned to pull all this out of the kernel but then somehow the
rv tool allows ftrace, perf, and console to continue to work with
violations? (For example, by somehow defining kprobes for violations
and writing violation information to /dev/kmsg?) Or is the rv tool
supposed to provide its own DIY variant of these features?

My plan isn't particularly strict right now. I'm aiming to allow BPF
monitors in the user space tool as an exploratory effort.  I don't
think you would easily interact with ftrace/perf from those though.

If that's a requirement, you could probably call a kfunc from BPF and
attach a kprobe there. I would implement that from a reactor
(violations only).

That sounds like it could work. As long as there are kprobes in the call
stack of violations, I am happy.

For a pure printk reactor, I drafted an implementation that calls
directly printk_deferred(), Alexei is suggesting to write to /dev/kmsg
from user space what BPF passes.  Since you were the one suggesting
having a real printk, would your use-case favour either solution? I'd
expect some different latency if the log passes from BPF to /dev/kmsg,
but I'm not sure that's an issue for you.

A delayed kernel record is better than none. Although I really do not
see why it cannot simply call printk_deferred() directly. It is safe and
lockless. And it has the advantage of appropriate timestamping when
compared to any other printk's that may be happening at that time.

If we are already adding kfuncs for panics and violations, why the
resistance to printks?

John