Gabriele Monaco <[email protected]> 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
