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

[Gabriele Monaco <gmonaco@redhat.com>]

On Wed, 2026-10-21 at 10:13 +0200, Nam Cao wrote:
> John Ogness <john.ogness@linutronix.de> writes:
> > On 2026-10-19, Nam Cao <namcao@linutronix.de> wrote:
> > > John Ogness <john.ogness@linutronix.de> writes:
> > > > @namcao: Maybe you could chime in if you want the transitions as events.
> > > 
> > > No. Those are only useful for debugging RV itself and do not need to be
> > > upstream.
> > 
> > Sure, but debugging RV itself _is_ a use case. Especially when RV moves
> > to eBPF and lots of people will start writing their own RV monitors.
> 
> Right.
> 
> I wouldn't enable those by default though, it's way too much noises. As
> it's for debugging the model, we can have some sort of compile-time
> switch to turn it on.

That's almost what's happening already, in-kernel use tracepoints, gated by
static branches. Those are the closest thing you can get to a dynamic compile-
time switch (assuming such a thing can exist), it's patching the code.

BPF gets even closer to the concept, we use a volatile const flag, which is
constant for the JIT runtime but volatile for the compiler (not compiled out
when generating byte code). Before loading we set the value we want in the
object and the JIT compiler wipes away the unused branches.

But technicalities aside, we probably want tracepoints for events too, so
bpf_printk or whatever else.

Gabriele