Remove configurable assignment of signal numbers.

[patacongo]

Currently there are 31 possible signals. Zero is the NULL signal, Signals 1-29 are all of the standard signals, and 30-31 are available for real time signals. Applications may only allocate signals from this pool*.

The logic in include/signal.h assigns values to the the standard signals so that they agree with the signal number used by Linux. Logic in include/signal.h and sched/Kconfig seem to permit the reassignment of any value to the standard signals:

In sched/Kconfig for example:

config SIG_STOP
    int "SIGSTOP"
    default 19
     ---help---
         ...

With matching logic in include/signal.h

#ifndef CONFIG_SIG_STOP
#  define SIGSTOP       19
#else
#  define SIGSTOP       CONFIG_SIG_STOP
#endif

I say "seems to permit reassignment" of the standard signal numbers because this conditional logic cannot work. That is because:

• There only on 31 signal number support (signal zero, the NULL signal, is a special case).
• The remaining 2 are reserved for user real time signals and cannot be used for real time signals because real time signals have different properties and are reserved for use by applications for IPCs).

So what could you possibly re-assign those 29 signals to since there are only 29 available values? Certainly you could scramble up the signal numbers within that range of 29 signal numbers. But that is a really bad thing, we should not support them.

Hence, I propose that we remove this non-functional and potentially dangerous capability to reconfigure signal numbers. Currently, I see two MCUs under board that set SIGPIPE to 11 (the ancient lm3s6965-ek and sim:nimble). 11 is SIGSEGV.

Related to this: Many signals defined in header files and Kconfig files have not been updated since the standard signals were expanded and renumbered to match Linux. That has to be addressed to. What if someone is trying to use SIGABRT as an IPC???

In Kconfig files, default application/driver signal numbers should be based at SIGRTMIN. That should also be confined to the range of SIGRTMIN through SIGRTMAX.

I propose that reviewing and correcting real time signal numbers so that the usage is pristine should be a part of this change.

*PR #8885 increases the number of real time signals to 32, but that is not yet merged as of this writing.

[patacongo]

Configurable signal numbers should be removed because the feature is useless. But removing configurable signal numbers has another benefit. We can, for example, greatly simplify logic like that of strsignal(). @pkarashchenko has been looking into that and this would facilitate a good solution.

[xiaoxiang781216]

Yes, I think so: the configurable signal number make the thing more complex, but the benefit is very small.

[raiden00pl]

+1