On Thu, 03 Sep 2026 09:21:18 +0200 Gabriele Monaco <[email protected]> wrote:
> 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. > As RV would simply be a user of BPF and not modifying BPF infrastructure, I'm not so sure you have the jurisdiction to NAK it. It would be like me NAKing how you create a trace event. RV monitors are a very good way to make sure the system is preforming properly. This looks exactly like a perfect use case for using BPF instead of having to install modules. Either BPF is a tool for the kernel or it isn't. You can't judge where BPF gets used. You can only judge on modifications to BFP. -- Steve > 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]
