On Tue, Mar 21, 2023 at 9:11 PM Gregory Nutt wrote: > > Linux supports 64 signals. Originally it supported 32 signals but: > > The addition of real-time signals required the widening of the signal set > structure (/sigset_t/) from 32 to 64 bits. Consequently, various system > calls were superseded by new system calls that supported the larger signal > sets. > https://man7.org/linux/man-pages/man7/signal.7.html > > We really have the same issue, shouldn't the MAX_SIGNO value be changed > to 63? if it is left at 32 and all of the standard signals are enabled, > then there is not many signals left for real time signals.
== Question Part == Can those customs signals be implemented with ioctl/sysctl api or other standard mechanism that would provide system compliance with other OS? How would that change impact future software porting to NuttX when its big enough to run "big" applications known from our desktop platforms? Why use custom signals at all? :-P == SciFi Part == If custom signals are necessary, maybe a bitmask could be used, or signal class? For instance there could be 4 lower bits allocated for system signals and 4 higher bits allocated for "custom" signals with no warranty of interference? That would fit in one byte and should provide some sort of backward compatibility for the system part but still "custom" part may get collisions? Maybe system signals could stay POSIX compliant (in adherence to selected OS with stable API or a selected standard), while there would be another group of custom signals marked in a way there would be no collision? Whatever change it may impact future porting to / from NuttX :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
