You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Petro Karashchenko <pe...@gmail.com> on 2023/03/21 18:18:36 UTC
Should signal values be unique
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
Re: Should signal values be unique
Posted by Tomek CEDRO <to...@cedro.info>.
On Tue, Mar 21, 2023 at 7:53 PM Petro Karashchenko wrote:
>
> 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
Hopefully some useful hints :-)
https://www.man7.org/linux/man-pages/man7/signal.7.html
https://man.freebsd.org/cgi/man.cgi?query=signal&apropos=0&sektion=0&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html
https://en.wikipedia.org/wiki/Signal_(IPC)
I have just registered to The Open Group so we could have access to
the standards :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
On 3/21/2023 3:11 PM, Petro Karashchenko wrote:
> I've counted 28 signals specified in
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html and
> 2 (SIGUSR1 and SIGUSR2) are already reserved for application needs. So 31 -
> (28 - 2) == 5. One signal value is "reserved" for SIGWORK, so it makes 4
> signal values that can be used by application without any questions.
The real time signals are all sequentially numbered starting at SIGRTMIN
and going through SIGRTMAX.
I see another error. The standard signals are also in the range of
SIGRTMIN through SIGRTMAX. It should not be
#define SIGRTMIN MIN_SIGNO /* First real time signal */
#define SIGRTMAX MAX_SIGNO /* Last real time signal */
It should be:
#define SIGRTMIN (SIGIO + 1) /* First real time signal */
#define SIGRTMAX MAX_SIGNO /* Last real time signal */
Per POSIX (https://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html):
This header also declares the macros SIGRTMIN and SIGRTMAX, which
evaluate to integral expressions and, if the Realtime Signals
Extension option is supported, specify a range of signal numbers
that are reserved for application use and for which the realtime
signal behaviour specified in this specification is supported. The
signal numbers in this range do not overlap any of the signals
specified in the following table.
The range SIGRTMIN through SIGRTMAX inclusive includes at least
RTSIG_MAX signal numbers.
I will update the Issue to include this problem too.
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
> In the past, the signal numbers would automatically pack like:
>
> #ifndef CONFIG_SIG_INT
> # define SIGINT (SIGHUP + 1)
> #else
> # define SIGINT CONFIG_SIG_INT
> #endif
>
That is not right. I am mis-remembering. Getting old sucks.
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
Hi,
I think I answered this in my response to Tomasz for the most part.
Again, there are lots of online tutorials that will do a better job than
I. Like
https://www.softprayog.in/programming/posix-real-time-signals-in-linux
On 3/21/2023 3:11 PM, Petro Karashchenko wrote:
> I've counted 28 signals specified in
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html and
> 2 (SIGUSR1 and SIGUSR2) are already reserved for application needs. So 31 -
> (28 - 2) == 5. One signal value is "reserved" for SIGWORK, so it makes 4
> signal values that can be used by application without any questions.
>
> I came from a more "traditional" RTOS environment and despite that I
> started with Nucleus 2 that had implementation for signals (not POSIX of
> course), but nobody used it in that environment, so I need some more
> education here.
>
> When you are talking about "realtime signals", then what use case do you
> mean? Because per my understanding there is no way to do publish /
> subscribe with signals and signal number and process ID make a tuple, so
> same signal value can have a different meaning for process A and process B.
> The things seems to be more complicated in case of groups support.
Real time signals are used all over the code as a general IPC. Whenever
a signal is used as an IPC, versus as its pre-defined function, it is a
real time signal. It is really like any other signal except that its
default action is SIG_IGN (ignore) and they can always be caught.
We use them a lot for:
* Signalling events from interrupt handlers to OS code (or even
application code).
* Many drivers have a notification interface that permits an
application to register to receive an signal whenever some event
occurs in the OS. That is use in a POSIX OS much like callbacks are
used on other environments. There are no callbacks from the OS
under POSIX.
99% of the signals in the OS use these real time signals. There is less
use of the standard signals. SIGABRT or SIGINT can terminate a task if
enabled. SIGCHLD notifies of the death of a child task. SIGALRM means
that a timer has expired. I think a few others are used too.
> What is the number of "realtime signals" used in applications that are in
> the field?
Real time signals get the heavier use. But there are probably no more
than 3 or 4 per task -- typically for the above kind of uses. There can
really be severe design issues if you need more than a couple.
There is really no way to eliminate the standard signals. They will be
defined no matter what you do. but to define the signal to match Linux
be default. For example:
#ifndef CONFIG_SIG_INT
# define SIGINT 2
#else
# define SIGINT CONFIG_SIG_INT
#endif
You really have no option, SIGINT will be defined no matter what you
do. It will either be a value packed tight at the bottom of the signal
numbers or some other number somewhere else (maybe 29, 30, or 31). I
suppose you could eliminate it by defining to be the same as some other
signal, but that sounds very dangerous to me.
To me replacing the above with just:
#define SIGINT 2
would be a good thing to whether or not you increase the number of
signals. The number of signals is really another closely related
discussion.
One thing to do would be to (1) eliminate these mostly useless per
signal configurations and (2) just ask for the number of real time
signals with a default of 2 and an option of 63, then conditionally make
the sigset_t either 32- or 64-bits.
In the past, the signal numbers would automatically pack like:
#ifndef CONFIG_SIG_INT
# define SIGINT (SIGHUP + 1)
#else
# define SIGINT CONFIG_SIG_INT
#endif
> I would like to understand the issue deeper before rushing with the
> solution. We can adapt most of the modern MCUs to use uint64_t as
> segnal set holder (that of cause is depending on CONFIG_HAVE_LONG_LONG and
> some compilers will not have that), but that will leave less powerful
> variants with 32 bit signal set as a fallback. Maybe for those systems we
> do not need so many realtime signals, so that will be an "easy win".
Another option would be an array of uint32_t's with dimension determined
by the number of signals.
Greg
Re: Should signal values be unique
Posted by Petro Karashchenko <pe...@gmail.com>.
I've counted 28 signals specified in
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html and
2 (SIGUSR1 and SIGUSR2) are already reserved for application needs. So 31 -
(28 - 2) == 5. One signal value is "reserved" for SIGWORK, so it makes 4
signal values that can be used by application without any questions.
I came from a more "traditional" RTOS environment and despite that I
started with Nucleus 2 that had implementation for signals (not POSIX of
course), but nobody used it in that environment, so I need some more
education here.
When you are talking about "realtime signals", then what use case do you
mean? Because per my understanding there is no way to do publish /
subscribe with signals and signal number and process ID make a tuple, so
same signal value can have a different meaning for process A and process B.
The things seems to be more complicated in case of groups support.
What is the number of "realtime signals" used in applications that are in
the field?
I would like to understand the issue deeper before rushing with the
solution. We can adapt most of the modern MCUs to use uint64_t as
segnal set holder (that of cause is depending on CONFIG_HAVE_LONG_LONG and
some compilers will not have that), but that will leave less powerful
variants with 32 bit signal set as a fallback. Maybe for those systems we
do not need so many realtime signals, so that will be an "easy win".
Anyway I need some more information to scope the work.
Best regards,
Petro
вт, 21 бер. 2023 р. о 22:11 Gregory Nutt <sp...@gmail.com> пише:
> 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.
>
> On 3/21/2023 1:56 PM, Gregory Nutt wrote:
> > I think I am mixing three related things here:
> >
> > 1. OPEN_MAX which controls the number of open files. That is 256
> > 2. FD_SETSIZE which is the size of the fd_set. That is the set passed
> > to select()
> > 3. Number of signals MAX_SIGNO which is really almost unrelated. It is
> > only related through opening signals.
> >
> > I get myself confused at time so don't take this too seriously. I am
> > probably inflating the issue.
> >
> > Greg
> >
> > On 3/21/2023 1:41 PM, Gregory Nutt wrote:
> >>
> >>> 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.
> >>
> >>
> >>
> >>
> >
>
Re: Should signal values be unique
Posted by Tomek CEDRO <to...@cedro.info>.
Thank You Greg! :-) :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
> == 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?
I'm not sure that I understand. The 31 signals work fine now: The
pre-defined signals as well has the real time signals. To increase the
number of signals means essentially that a signal set becomes an array.
Not really too complex.
Currently, up to 29 pre-defined signals could be enabled (although not
all are supported). If the limit is 31, then that leaves on 2 for real
time signal support.
> Why use custom signals at all? :-P
Real time signals is a standard IPC. It is one of the most common IPCs
used in the OS. A common use is to signal a driver that and interrupt
level event has occurred.
Google for posix real time signals. There are lots of good tutorials
like: https://www.softprayog.in/programming/posix-real-time-signals-in-linux
> == 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?
You are describing just how it works now. You are describing type
sigset_t. See include/signal.h
> 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 :-)
Real time signals aren't "custom." The are standard and are support
just like the pre-defined signals except that they have no default
actions. All of the standard signal APIs are support. They are
identical in all ways up to the point where the signal is delivered to
the recipient and the default action occurs. There also some small
differences in regard to which signals can be caught and which cannot.
Greg
Re: Should signal values be unique
Posted by Tomek CEDRO <to...@cedro.info>.
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
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
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.
On 3/21/2023 1:56 PM, Gregory Nutt wrote:
> I think I am mixing three related things here:
>
> 1. OPEN_MAX which controls the number of open files. That is 256
> 2. FD_SETSIZE which is the size of the fd_set. That is the set passed
> to select()
> 3. Number of signals MAX_SIGNO which is really almost unrelated. It is
> only related through opening signals.
>
> I get myself confused at time so don't take this too seriously. I am
> probably inflating the issue.
>
> Greg
>
> On 3/21/2023 1:41 PM, Gregory Nutt wrote:
>>
>>> 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.
>>
>>
>>
>>
>
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
I think I am mixing three related things here:
1. OPEN_MAX which controls the number of open files. That is 256
2. FD_SETSIZE which is the size of the fd_set. That is the set passed
to select()
3. Number of signals MAX_SIGNO which is really almost unrelated. It is
only related through opening signals.
I get myself confused at time so don't take this too seriously. I am
probably inflating the issue.
Greg
On 3/21/2023 1:41 PM, Gregory Nutt wrote:
>
>> 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.
>
>
>
>
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
Re: Should signal values be unique
Posted by Petro Karashchenko <pe...@gmail.com>.
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 <sp...@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
> >
>
>
Re: Should signal values be unique
Posted by Gregory Nutt <sp...@gmail.com>.
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
>