On Fri Sep 4, 2026 at 10:24 AM PDT, Steven Rostedt wrote: > On Fri, 4 Sep 2026 12:31:08 -0400 > Steven Rostedt <[email protected]> wrote: > >> In the beginning, Daniel Bristot looked into doing this with BPF and found >> issues with it. I do not recall what they were and unfortunately Daniel is >> no longer around to explain it. Maybe Gabriele knows what they were. > > IIRC, Daniel even told me there was a competing effort within Red Hat to > implement the same functionality using only BPF. That effort never > materialized and everything went toward the RV code Daniel was working on.
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.
