On Fri, Sep 4, 2026 at 4:45 PM Steven Rostedt <[email protected]> wrote: > > On Fri, 04 Sep 2026 16:34:00 -0700 > "Alexei Starovoitov" <[email protected]> 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.
