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

[John Ogness <john.ogness@linutronix.de>]

On 2026-10-22, Gabriele Monaco <gmonaco@redhat.com> 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