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

[Steven Rostedt]

On Thu, 03 Sep 2026 09:21:18 +0200
Gabriele Monaco <gmonaco@xxxxxxxxxx> 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/20260522125833.264145-1-gmonaco@xxxxxxxxxx
> [2] - https://lore.kernel.org/lkml/20260113085159.114226-3-gmonaco@xxxxxxxxxx
> [3] -
> https://lore.kernel.org/linux-rt-users/20260826132153.2476006-1-bigeasy@xxxxxxxxxxxxx/T/#t
> [4] -
> https://lore.kernel.org/lkml/20260827072400.45734-1-tobias.schaffner@xxxxxxxxxxx