On Wed, 21 Oct 2026 13:54:04 +0200 Gabriele Monaco <[email protected]> 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
