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

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 4 Sep 2026 16:48:55 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Fri, Sep 4, 2026 at 4:45 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Fri, 04 Sep 2026 16:34:00 -0700
> > "Alexei Starovoitov" <alexei.starovoitov@gmail.com> 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.

-- Steve


-- Steve