On 7/28/2020 11:48 AM, Morten Brørup wrote: >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger >> Sent: Monday, July 27, 2020 9:44 PM >> >> On Mon, 27 Jul 2020 15:19:32 +0200 >> Morten Brørup <m...@smartsharesystems.com> wrote: >> >>>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen >> Hemminger >>>> Sent: Wednesday, July 15, 2020 1:58 AM >>>> >>>> SIGIO maybe used by application, instead choose another rt-signal. >>>> Linux allows any signal to be used for signal based IO. >>>> Search for an unused signal in the available rt-signal range. >>> >>> Just an observation. Feel free to ignore at your convenience: >>> >>> The problem is the same as for SIGIO if the application sets up its >> own signal handler after this, and uses some hardcoded rt-signal that >> happens to be the one found to be free. >>> >>> Unless the application doesn't use a hardcoded rt-signal, but also >> searches for an unused one. >>> >>> So perhaps the "search for unused rt-signal" should be exposed as a >> generic support function for the application (and this driver) to use. >> >> There is no safe way to use a signal deep inside DPDK in a driver. >> >> This is not the kind of thing that should be exposed to the >> application. >> >> The algorithm for finding an RT signal conforms to the recommended >> policy on the signal(7) >> manual page. >> >> programs should never refer to real-time signals using hard- >> coded numbers, but instead should always refer to real-time >> signals >> using the notation SIGRTMIN+n, and include suitable (run-time) >> checks >> that SIGRTMIN+n does not exceed SIGRTMAX. >> >> The application should be following the proscribed policy on the man >> page. >> If it doesn't it is broken. > > Great. That fully addresses my concern. > > Acked-by: Morten Brørup <m...@smartsharesystems.com> >
Reviewed-by: Ferruh Yigit <ferruh.yi...@intel.com>
