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:
(...) > > > 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
