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

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 21 Oct 2026 13:54:04 +0200
Gabriele Monaco <gmonaco@redhat.com> wrote:

> > I vote 1, much simpler (but maybe I just haven't quite got the issue). I
> > feel a bit ensure about adding RV kfuncs and would only go that route if
> > there is no other way.  
> 
> We can go down that route and see how it behaves.

BTW, I'm curious if it isn't possible to keep both in-kernel and BPF
monitors? That is, for those cases that do not change often and has a well
known model, to simply keep those as modules and hard coded.

But this entire thread started with people that wanted BPF type of
monitors for more flexibility. I would argue that is an entirely separate
use case. For them, it should be a fully BPF solution, with a few hooks
into the RV infrastructure.

It currently is a big unknown if the BPF solution can handle all the use
cases of the current module method. My suggestion is to not try to do so.
Keep the module method for the more static use cases that do not need
dynamic changes. And create a purely BPF method for those that need BPF.

This thread is sounding like there's different requirements between the BPF
and module methods. If that's the case, let's keep them separate.

I agree with Alexei's first comment about not adding BPF to the module
method. But that doesn't mean we need to eliminate the module method
completely in order to use BPF. Instead, just create a new BPF pure method.

Perhaps in the future the BPF method may make the module method obsolete,
but I don't want users of the module method having to do all these
workarounds just to satisfy the BPF method while it is in development.

-- Steve