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

[Gabriele Monaco <gmonaco@redhat.com>]

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/20260522125833.264145-1-gmonaco@redhat.com
[2] - https://lore.kernel.org/lkml/20260113085159.114226-3-gmonaco@redhat.com
[3] -
https://lore.kernel.org/linux-rt-users/20260826132153.2476006-1-bigeasy@linutronix.de/T/#t
[4] -
https://lore.kernel.org/lkml/20260827072400.45734-1-tobias.schaffner@siemens.com