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

[Steven Rostedt]

On Fri, 04 Sep 2026 16:34:00 -0700
"Alexei Starovoitov" <alexei.starovoitov@xxxxxxxxx> wrote:

> bpf in 2022 was surely less capable then it is today.
> It took us 2 years of bpf core development to statisfy sched-ext demands
> and we're still adding new features for sched-ext needs.
> If you're trully willing to remove 90% of kernel/trace/rv/ and refactor
> it into tiny shim where all of the core pieces are bpf driven we can
> certainly work together (like we did with sched-ext) and add whatever
> is missing on bpf side. Then all existing monitors will become bpf programs.
> But adding bpf as another 'monitor', sorry but hard NO.
> If hardcoded monitors was a mistake then admit it and fix it by deleting it,
> if it's not a mistake then keep adding hardcoded monitors.

Regardless of whether or not BPF can replace "hardcoded monitors" today, it
wasn't a mistake back then if BPF wasn't able to do it when they were first
being added. sched_ext wanted to use BPF for scheduling as module plugins
were nack'd by the scheduler maintainers for a long time. BPF programs to
handle scheduling was the work-around to that, and basically the only way
forward. And it still required special hooks into the scheduler.

The rv monitors only needed to use tracepoints for hooks. A module was the
easiest way to get there, as BPF at the time wasn't an option.

If you want to use hostile language like "admit you made a mistake" then it
makes it harder to collaborate.

-- Steve