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

[Alexei Starovoitov]

On Fri Sep 4, 2026 at 4:43 AM PDT, Steven Rostedt wrote:
> On Thu, 3 Sep 2026 20:30:19 -0700
> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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.  
>> > >
>
>> 
>> Ok.
>> Please add
>> Nacked-by: Alexei Starovoitov <ast@xxxxxxxxxx>
>> 
>> when you submit it to Linus.
>> Let him decide whether bpf maintainers have an authority
>> to say where bpf is used in the kernel.
>
> When this is ready, I'll be happy to inform Linus on the pull request
> that you NACKed it, if you are still against it by then. He's Cc'd on
> this conversation now. But you left out any technical reason for the
> NACK. You basically just said "I don't see how this is useful to me".
> That's not a valid reason for a NACK.

You added a whole bunch of hardcoded "monitors". None of them were
necessary. The whole RV is imo a waste of kernel code.
All of that could have been done via existing bpf tracing functionality.
One can delete kernel/trace/rv and do the same thing with bpf.
So I'm strongly against bolting bpf to RV as yet another "monitor".
It's a wrong design. Keep adding hard coded monitors and don't mess
with bpf.

> Gabriele will be presenting this work at Linux Plumbers[1]. This will

I didn't vote for it. Other bpf maintainers did. Hence it's in schedule.
But my stance is still a nack.