On Wed, 2026-10-21 at 18:53 +0206, John Ogness wrote: > On 2026-10-21, Gabriele Monaco <[email protected]> wrote: > > > BTW, I'm curious if it isn't possible to keep both in-kernel and BPF > > > monitors? That is, for those cases that do not change often and has a > > > well known model, to simply keep those as modules and hard coded. > > > > In my opinion it is possible and I'm designing every change with that > > coexistence in mind. > > > > I would say we could only drop in-kernel if BPF does such a great job > > to cover every single technical and non-technical requirement or > > use-case, AND if it makes maintaining the whole thing easier. > > I am wondering if coexistence should be the goal. For example, the > monitor classes (DA, LTL, HTA) are only implemented in the kernel and > provide kfuncs for the state transition functions to be available to BPF > monitors. I would expect that this would allow BPF monitors to have the > full functionality as in-kernel monitors, since the events, errors, and > reactors would all trigger from the monitor class code.
Well, this would be yet another hybrid requiring BPF monitors registration in the kernel like I proposed in the RFC [1], which was the main point of contention (that fully shared reactors and sysfs interface, by the way). For this I would argue, though, that such monitors would be BPF just on paper, we wouldn't be able to use many advantages BPF provides (e.g. BPF maps). The current implementation already shares the header with in-kernel monitors, so the actual logic is shared. What isn't shared is the storage type and some glue around it. I used BPF maps because they offer some nice flexibility especially around per- task and per-obj monitors. On top of using more battle tested code. I would like to keep that. Besides, we'd need to be extra careful on controlling the callers. Right now handlers are static, so it's easier to make sure no rogue caller messes up with monitoring. What else definitely isn't shared, which is the main point of this whole conversation, is trace events. Those could be kfuncs. And no matter what you do, BPF monitors will need to share the trace events (unlike in-kernel that have separate events per monitor). In short, I don't think this would be easy to achieve and wouldn't earn us that much. (Plus I'd lose the hardly earned Alexei's blessing ;) ) What do you think? Gabriele [1] - https://lore.kernel.org/lkml/[email protected]
