On Sat, 2026-10-17 at 17:23 +0206, John Ogness wrote: > On 2026-10-17, Gabriele Monaco <[email protected]> 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
