On 8/17/2020 4:26 PM, Ferruh Yigit wrote: > 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> >
Applied to dpdk-next-net/main, thanks.
