On Wed, 2026-10-21 at 10:13 +0200, Nam Cao wrote: > John Ogness <[email protected]> writes: > > On 2026-10-19, Nam Cao <[email protected]> wrote: > > > John Ogness <[email protected]> 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
