Re: [RFC PATCH 00/20] rv: Add support for BPF monitors

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 1, 2026 at 11:52 PM PDT, Gabriele Monaco wrote:
> On Tue, 2026-09-01 at 20:35 +0200, Nam Cao wrote:
>> Gabriele Monaco <gmonaco@redhat.com> writes:
>> > Extend the rv userspace tool to load BPF monitors, those can be found in
>> > specific locations (e.g. /usr/share/rv/bpf_monitors/) and are plain
>> > object files including BTF data.
>> > 
>> > This type of BPF monitors can be generated from rvgen using the -b flag
>> > just like in-kernel monitors and, after manual adaptation, can be built
>> > and run transparently by the rv userspace tool.
>> 
>> I am not familiar with BPF. What is the benefit of BPF monitors,
>> compared to the existing DA monitors?
>
> I should definitely have included it in the cover letter.. I'm writing it
> everywhere (will present at LPC) but forgot it here.
>
> Essentially BPF monitors can be pluggable, folks writing their own monitors
> won't need to submit a patch or maintain a separate tree, which is useful for
> domain-specific models.
> By being pluggable you also don't need to reboot to use a new/updated monitor.
>
> Think of being able to distribute a more granular set of rules for RTapp, I
> remember we had conversation along those lines, not all rules apply to all
> contexts and what you send upstream has to be general, what you keep for
> yourself doesn't.
>
> Having monitors in BPF brings also other perks over kernel modules: a whole
> bunch of readily available probe types (uprobes, fprobes, all unexported
> tracepoints that are cumbersome for modules), the map infrastructure for
> allocation is arguably easier and the code is verified when loaded against
> common issues (NULL pointer access, unbound loops, etc.).
>
> That said, I try to mimic as much as possible the in-kernel functionality, but
> some things are not the same (event/error tracepoints).
>
> These support DA only because BPF loading needs a userspace component and the RV
> tool doesn't support LTL and HA yet, there shouldn't be any technical reason not
> to extend to those in the future.

I don't think bpf fits here. I haven't seen active use of RV and even less
so of any request from people who want this kind of programmability.

So Nack for now. Sorry.