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

[Nam Cao]

Gabriele Monaco <gmonaco@xxxxxxxxxx> writes:
> 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.

Cool. I also wanted to do something like this, for these exact same
reasons. Let me look at your patches..

Nam