Il 5 settembre 2026 00:22:01 UTC, Alexei Starovoitov
<[email protected]> ha scritto:
>On Fri, Sep 4, 2026 at 5:16 PM Steven Rostedt <[email protected]> wrote:
>>
>> On Fri, 4 Sep 2026 16:48:55 -0700
>> Alexei Starovoitov <[email protected]> wrote:
>>
>> > 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.
Alexei, what I read from your opinion is: if you really want to do this RV
thing, then you should just implement it all in BPF.
Please correct me if I'm wrong, but I don't see how this series isn't a step
towards it. I am obviously open to all sorts of criticism on /how/ I'm doing it.
We are adding the possibility to write (existing or new) monitors in BPF, not
adding another fat "bpf monitor".
And if you believe my attempt to have in-kernel and BPF monitors coexist is a
waste of time, I get that too and I'm open to discuss.
As you mentioned, when the project started, BPF was just not ready. My
intention with this series is to reassess this today.
RV was initially built with the functional safety use-case in mind. For various
technical reasons this didn't take off, but that scenario drove towards
implementing RV reactors like the panic() one. Something BPF just shouldn't do,
as I get it.
The interoperability with other tools (via RV-generated tracepoints) was also a
driving factor, together with Daniel probably being more proficient with those
back then.
That's just from the top of my head: there are historical and technical reasons
for why RV looks like it is today, whether those are valid or just "mistakes"
is simply not for us to say.
I'd rather discuss on what is the best approach /today/. And that's precisely
why I submitted the talk for LPC.
Gabriele
