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

[Alexei Starovoitov]

On Fri, Sep 4, 2026 at 5:16 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Fri, 4 Sep 2026 16:48:55 -0700
> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
>
> > On Fri, Sep 4, 2026 at 4:45 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > >
> > > 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.
> >
> > If you're offended by the word "mistake" then ok. There is no path forward.
> > Keep adding hardcoded stuff.
>
> I'm not offended by the words, I'm offended by your tone. As BPF was
> insufficient when RV started, it obviously wasn't a mistake that we didn't
> use it. If you are just going to say it was a mistake because we didn't
> modify BPF to suite our needs (which I highly doubt you would have wanted
> to help us, as you already stated that you don't care about this project),
> then you are obviously biased against us.
>
> Your response was fine until you through in that last sentence. As making a
> mistake means that the other non-mistake option was viable at the item. It
> wasn't.
>
> Look, if BPF has changed so much that it could be re-evaluated to see if it
> suits the needs of RV, then sure. We could look into doing that. Perhaps it
> can replace the hard-coded monitors. But what we have been doing has not
> been a mistake. Saying so is a bit disrespectful to the project and a
> direct insult to Daniel.

I respectfully disagree. Let's stop here.