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

[Gabriele Monaco <gmonaco@redhat.com>]

On Wed, 2026-10-21 at 09:48 -0400, Steven Rostedt wrote:
> 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.

In my opinion it is possible and I'm designing every change with that
coexistence in mind.

I would say we could only drop in-kernel if BPF does such a great job to cover
every single technical and non-technical requirement or use-case, AND if it
makes maintaining the whole thing easier.

But I'd like both to be fully ready upstream before taking that decision, though
I'm getting more and more sceptical.

> 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.

Agree, from the initial survey I had it seems some folks still prefer in-kernel
monitors with current infrastructure and cannot migrate (e.g. cannot build BPF
in their kernels).

Right now we're trying to understand what are the non-negotiables also BPF must
have and it seems we need some sort of tracepoints (via bpf_printk or something
more convoluted).
That makes it converge even closer to the in-kernel monitors usage, although it
still isn't a drop in replacement.

Reactors will stay, just probably not in BPF for now.

But thanks for chipping in, I fully agree.

Gabriele