Re: [RFC PATCH 00/20] rv: Add support for BPF monitors
From: Alexei Starovoitov <hidden>
Date: 2026-09-03 01:57:05
Also in:
bpf, lkml
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:quoted
Gabriele Monaco [off-list ref] writes:quoted
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.