On Thu, Sep 3, 2026 at 6:01 AM Steven Rostedt <[email protected]> wrote: > > 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.
Ok. Please add Nacked-by: Alexei Starovoitov <[email protected]> when you submit it to Linus. Let him decide whether bpf maintainers have an authority to say where bpf is used in the kernel.
