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.
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,
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 s
Thank You Greg! :-) :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
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 app
== 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
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 sup
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 se
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 openin
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/iss
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 t
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
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
On Tue, Mar 21, 2023 at 4:02 AM Nathan Hartman wrote:
> On Mon, Mar 20, 2023 at 10:36 PM Gregory Nutt wrote:
> > > NuttX offers a function clock_synchronize() that synchronizes system
> > clock
> > > with clock from RTC (internal or external). The synchronization is done
> > > during board initiali
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
What is your view on adding some sort of automatic synchronization that
would ensure system clock stays in sync with RTC (or at least error is less
than some value) even when i drifts away from "real time"? Quite simple
solution is to let clock_gettime() to update base time after N reads howeve
No, I don't want to do this from application level hence why I am looking
for an alternative. NuttX also has function clock_resynchronize() that
should solve the problem with time going backwards but not sure if it has
ever been tested and used.
There is an RTC timer driver in drivers/timers
> You wouldn't really do this from application level, right?
No, I don't want to do this from application level hence why I am looking
for an alternative. NuttX also has function clock_resynchronize() that
should solve the problem with time going backwards but not sure if it has
ever been test
18 matches
Mail list logo
