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
