I think I missed the change that expanded signal values to 255 and I think
that GOOD_SIGNO() macro still checks for <= 31.
These 463a4377331, 24bd80eb84d, fa3e0faffcb, 10852dcc25c
Yes, MAX_SIGNO and GOOD_SIGNO are wrong. I also created an Issue for
this: https://github.com/apache/nuttx/issues/8869 . I have not
carefully analyzed those, but it looks like there could be lots of
issues if the signal number is > 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).
Well, if we want to proceed this way I think we only need to publish the
breaking change in this dev list as a proper notice of the change.
Signal numbers are really arbitrary (other than when used with the kill
command) and it certainly can't make any technical difference which
numbers are used for which signals.
It used to be that if a system used a lot of "realtime signals", i.e.,
those with no pre-defined meaning, then you might need to change some of
the standard signals to pack them down to free up more for use as
pre-defined signals. But that should not longer be necessary.
