On Tue, 2026-09-01 at 20:35 +0200, Nam Cao wrote: > Gabriele Monaco <[email protected]> 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. Gabriele
