On 2026-10-19, Gabriele Monaco <[email protected]> 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
