On Wed, 2026-09-02 at 18:57 -0700, Alexei Starovoitov wrote: > 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.
Thanks for your opinion, however it sounds a bit harsh to me. RV is clearly not a popular tool, but I wouldn't say it doesn't have active use: we're actively using it to validate the deadline scheduler/server changes and it already found a number of issues (e.g. [1], [2]). The RTapp monitors are used to validate if userspace real-time applications interact with the kernel in the best way for predictability, as far as I'm aware that's regularly used [3]. In my eyes, the missing piece of RV is in fact this programmability. Adding a monitor now requires to write in-tree built-in kernel code. There are strong use cases for domain-specific rules that aren't general enough to belong in the kernel tree: * stricter RTapp rules that may not apply to all use-cases * verify some exotic system within Linux (e.g. a co-kernel [4]) * modelling for functional safety certification process (used for in-vehicle OSes like RHIVOS) BPF seems the natural tool for the job to me. Mind that RV monitors would be simple users of BPF, requiring only modifications in the RV subsystem but using standard BPF facilities. I'm totally open to discuss on this though. Thanks, Gabriele [1] - https://lore.kernel.org/lkml/[email protected] [2] - https://lore.kernel.org/lkml/[email protected] [3] - https://lore.kernel.org/linux-rt-users/[email protected]/T/#t [4] - https://lore.kernel.org/lkml/[email protected]
