Re: [PATCH v2 09/15] tools/rv: Copy stripped bpf_atomic.h from libarena

[Gabriele Monaco <gmonaco@redhat.com>]

Hi Steve,

On Sat, 2026-10-10 at 20:43 -0400, Steven Rostedt wrote:
> 
> Please keep both until you know the BPF side can do everything you need.

I agree. Also, complex monitors like timed automata won't be as easy to migrate.

> 
> On Fri, 09 Oct 2026 12:09:42 +0200
> Gabriele Monaco <gmonaco@redhat.com> wrote:
> 
> > There's a common belief considering BPF a prototyping playground, where
> > "real"
> > things should eventually end up in the kernel.
> > Now, I don't agree with it (look at the many sched_ext policies used in
> > production), but I'd want to assess if dropping kernel support could drive
> > users away (e.g. industry/automotive which keeps popping out) and understand
> > the various not purely technical reasons.
> 
> Where do you plan on storing the repository of BPF programs?

That's something I would like to refine better. But I'm planning to keep
"official" monitors in-tree (tools/rv) and encourage to upstream monitors
nonetheless.

We could come up with a separate repository for "community" monitors, with
perhaps a lower bar compared to the ones in-tree. That'd hopefully encourage
collaboration where possible.

> One issue I have with sched_ext is that it did exactly what many people
> were worried about. There's a lot of schedulers out there without much
> collaboration. It's the "copy one close to what I want and tweak it".
> When I left Google, I heard there was 20 or so sched_ext schedulers
> doing various things for various projects.
> 
> One of my main motivations for scheduler governors.

Yeah that's a good point, though I'm not quite sure how to prevent that.
People could do mostly the same using kernel modules as well, however.

At the moment I still didn't figure out how to build monitors out-of-tree, that
might encourage a bit more working in-tree.

The difference with sched_ext here is that this BPF implementation requires
little to none kernel support. For all we know, people out there might already
be running something like RV monitors implemented in BPF or whatever else.

Currently most of the logic is supposed to go to the shared headers, but
monitors can implement some custom logic too (you already need to touch the C
file anyway). I'd like to reduce reliance on custom logic as much as possible,
that was already brought up by a couple of people. This way, hopefully, people
would rely more on the "library" and share/request any improvement.

But again, I don't have real answers to that, and I'm open to discuss more
sensible solutions.

Thanks,
Gabriele