On Mon, Oct 06, 2025 at 05:19:24PM +0200, Gabriele Monaco wrote:

On Mon, 2025-10-06 at 12:10 +0200, Thomas Weißschuh wrote:

(...)

quoted

quoted

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?

The signal reactor is convenient to write automated tests. It can be used to
validate the monitors by triggering known-bad systemcalls from a test
executable and expect it to be killed with the reactor signal, see below for
an example.
On the other hand it can be used to validate that the kernel itself does not
regress with respect to RV-validated properties. For example the test program
can enable the rtapp monitor and run an example RT application using all kinds
of known-good IPC mechanisms without it being killed.

Yeah, what I meant is: having a signal isn't your goal. Easily understand if
there was a reaction is.
You could even restructure your test using tracepoints without any signal.

Agreed.

So if I get it correctly, you are both "voting" for removing reactors in favour
of tracepoint-only error reporting.
Am I getting this right?

No, it is a suggestion for a cleanup/optimization where reactors are not
directly called from the monitors but instead from a tracepoint which is
triggered from the monitors. It would decouple the monitor and reactor
subsystems.


Thomas