On Mon, 2026-10-19 at 11:16 +0206, John Ogness wrote: > 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.
Yeah of course, I meant more that you need to call both tools (start the monitor /and/ the tracing). At most I'd have a -e flag in rv (just like rtla has, mirroring trace-cmd functionality). But you're right, it's best if the other tools can do that first. > > 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). > That's an interesting idea actually. Thanks, Gabriele
