Hello Gregory, Thank you for your reply.
I think I missed the change that expanded signal values to 255 and I think that GOOD_SIGNO() macro still checks for <= 31. I will re-examine the code and find it out. I would be glad to clean-up the signal values reconfiguration code however recently I saw e-mail thread that some custom boards code may rely on reconfigured values. Anyway that can be a "breaking change" that will make things easier (IMO). Best regards, Petro On Tue, Mar 21, 2023, 8:37 PM Gregory Nutt <spudan...@gmail.com> wrote: > Hi, Petro, > > The first thing that I would want to know is: Is it really necessary to > be able to reconfigure signal numbers? Is there any real reason to do > that now? I put the configurable signal numbers in because there was a > limit of 31 signals. But recently, that has been extended to 255 > signals (configurable). > > So can we just get rid of the configurations and just make the signal > numbers fixed (and equal to the fixed numbers assigned by Linux)? > > That would make your job easier and, I think, clean up some useless > stuff in the OS. > > Greg > > On 3/21/2023 12:18 PM, Petro Karashchenko wrote: > > Hello team, > > > > Recently I've been looking into signal implementation and particularly > into > > strsignal() API. As a result I've drafted > > https://github.com/apache/nuttx/pull/8867 that intends to optimize the > > implementation, but during CI I found out that some configurations have > > different signal numbers defined to the same values. So my question is > > about how strsignal() should behave in such case? My initial approach was > > to use switch/case to select string corresponding to the signal number > > value, but if the values are duplicated (triplicated, etc.) then > > switch/case simply generate compilation error. > > > > I need some advice on how to implement/refine this properly. > > > > Best regards, > > Petro > > > >
