2025-10-02T14:56:23Z Nam Cao [off-list ref]:

Thomas Weißschuh [off-list ref] writes:

quoted

I am wondering if it would make sense to add a new tracepoint that
fires in addition of the reactors. That would allow multiple
simultaneous consumers and also bespoke handlers in userspace.

We do have tracepoints for each monitor in: kernel/trace/rv/rv_trace.h

And yeah, I think it is a nice idea for all the consumers to use these
tracepoints intead (that includes rtapp testing, and also the existing
reactors). It would simplify things, as the monitors do not have to
worry about the reactors, they only need to invoke tracepoints.

But this also makes me think about the necessity of the existing
reactors. What do they offer that tracepoints do not? Myself I almost
never use the reactors, so I'm thinking about removing them. But maybe
@Gabriele has objections?

Well, many use cases might be better off with tracepoints, but reactors do
things tracepoints cannot really do.
Printk is much faster (and perhaps more reliable) than the trace buffer for
printing, panic can be used to gather a kernel dump.
One may just attach to tracepoints via libtracefs/BPF and do most of the things
you'd want to do with a new reactor, but I see reactors much easier to use from
scripts, for instance.

LTLs don't benefit as much as they don't print any additional information via
reactors, but DA/HA give hints on what's wrong.

I wouldn't get rid of reactors until they become a huge maintenance burden, but
probably we could think about it twice before extending or making them more
complex.

For instance, what's the exact use case of the signal reactor? Isn't it simpler
to do everything in BPF? Is the signal needed at all or something else (e.g.
perf) would do the job?

Thoughts?

Gabriele