> 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>
