On Fri Sep 4, 2026 at 4:43 AM PDT, Steven Rostedt wrote: > On Thu, 3 Sep 2026 20:30:19 -0700 > Alexei Starovoitov <[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. >> > > > >> >> 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. > > 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.
