On 2026-10-22, Gabriele Monaco <[email protected]> wrote: >> I am wondering if coexistence should be the goal. For example, the >> monitor classes (DA, LTL, HTA) are only implemented in the kernel and >> provide kfuncs for the state transition functions to be available to BPF >> monitors. I would expect that this would allow BPF monitors to have the >> full functionality as in-kernel monitors, since the events, errors, and >> reactors would all trigger from the monitor class code. > > Well, this would be yet another hybrid requiring BPF monitors registration in > the kernel like I proposed in the RFC [1], which was the main point of > contention (that fully shared reactors and sysfs interface, by the way).
I think there is a difference, because the registration could be via kfunc interface rather than requiring kernel patches. Similarly, the kernel is able to load drivers that it does not know about it advance. > For this I would argue, though, that such monitors would be BPF just > on paper, we wouldn't be able to use many advantages BPF provides > (e.g. BPF maps). It seems to me that your main motivation of BPF is to move the RV-machinery into BPF. For example, moving include/rv/ltl_monitor.h into BPF. But that code should not require the flexibility that BPF offers. It is the monitors themselves that I think benefit from BPF. For example, kernel/trace/rv/monitors/wakeup/wakeup.c I do not understand why you would call it BPF on paper, when the semantics of the states and transitions is all coded in BPF. Everything that makes two monitors using the same monitor class different from each other. Only the generic state machine (with its tracepoints for events and errors) and calling of reactors is in the kernel. > The current implementation already shares the header with in-kernel monitors, > so > the actual logic is shared. When you say "shared" you really mean "copied". If it was "shared" (in the kernel) then the whole tracepoint/reactor topic would nearly solve itself. > Besides, we'd need to be extra careful on controlling the callers. Right now > handlers are static, so it's easier to make sure no rogue caller messes up > with > monitoring. That problem is orthogonal. But I expect kfunc flags, capabilities, and/or signed BPF objects will be the direction to take. The reason for my suggestion of a "true" hybrid approach is because I feel like you were trying to completely relocate RV to BPF, and now due to the tracepoint/reactor requirements, we're trying to find some hacks to somehow make it work good enough. I was suggesting to take a step back and consider an approach where there are in-kernel pieces to leverage the benefits of in-kernel (generic state machine, tracepoints, reactors) and BPF pieces to leverage the benefits of BPF (freedom to define the semantics of states and transitions for any domain-specific monitor). John
