You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by mg...@duckeck.eu on 2026/02/05 15:30:49 UTC
Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Hello,
I have problems with the following commit, which is part of PR #17199
commit c7b6442974545b92476615ef048633609d828e5b
Author: wangchengdong <wa...@lixiang.com>
Date: Mon Oct 13 20:57:43 2025 +0800
sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
Improve nxclock_gettime(), to get the system time excluding
the time that the system is suspended, when the clockid is
CLOCK_MONOTONIC
Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
This commit changes the behaviour of CLOCK_MONOTONIC. It is running slower than CLOCK_BOOTTIME now.
I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line 143 in nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used CLOCK_MONOTONIC to calculate the value "abstime", but wd_start_abstime() uses CLOCK_BOOTTIME now. When the system in running for some time this leads to an immediate timeout, because two different clocks are compared.
int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
FAR const struct timespec *abstime)
{
...
if (clockid == CLOCK_REALTIME)
{
wd_start_realtime(&rtcb->waitdog, abstime,
nxsem_timeout, (uintptr_t)rtcb);
}
else
{
wd_start_abstime(&rtcb->waitdog, abstime,
nxsem_timeout, (uintptr_t)rtcb);
}
...
For my understanding the change of CLOCK_MONOTONIC is not correct.
According to the POSIX definition https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
On the other hand, if such a low level change is made, all usages should be reviewed. There a lot of places where CLOCK_MONOTONIC is used in the nuttx source code. And there are places like in nxsem_clockwait() where the change leads to an error even though CLOCK_MONOTONIC is not used in the code.
What do you think?
BR,
Mathias
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by kr...@kerogit.eu.
> In my opinion, the main problem is that CLOCK_MONOTONIC's behaviour has
> been changed. This means that all uses of CLOCK_MONOTONIC must be
> checked and possibly changed. In nuttx, in the nuttx apps and in the
> all applications of all nuttx users!
> Am I the only one who had problems with that?
Well, things like these probably should not be done as lightly -
breaking other people's code likely has some degree of negative impact
on their perception of the project as a whole. I know that from my own
experience, I was just hit by commit 2d768c294ee34f
(Yes, this post is a bit of a poke ;-) I'll look into fixing the board.)
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by mg...@duckeck.eu.
Hi Chengdong,
> I submitted a PR (#18437) to address the CLOCK_BOOTTIME and CLOCK_MONOTONIC
> time source issue. Could you please take a look when you have a chance?
That's okay, you fixed a change that was made by commit 1c643b5cc on 30dec25.
> So my suggestion is not to use CLOCK_MONOTONIC for nxsem_clockwait. if you
> do not want the behavior you mentioned.
That's not a solution. If nxsem_clockwait is only working as expected for
CLOCK_REALTIME and CLOCK_BOOTTIME, it should al least return an error for other values.
In my opinion, the main problem is that CLOCK_MONOTONIC's behaviour has been changed. This means that all uses of CLOCK_MONOTONIC must be checked and possibly changed. In nuttx, in the nuttx apps and in the all applications of all nuttx users!
Am I the only one who had problems with that?
BR,
Mathias
chengdong wang schrieb am 25.02.2026 03:46 (GMT +01:00):
> Hi Mathias,
>
> I submitted a PR (#18437) to address the CLOCK_BOOTTIME and CLOCK_MONOTONIC
> time source issue. Could you please take a look when you have a chance?
>
> Regarding the error you mentioned, I think it should be expected behavior,
> because CLOCK_MONOTONIC excludes the time the system is suspended while the
> wdog for sem timeout using the time that includes the suspended period.
>
> So my suggestion is not to use CLOCK_MONOTONIC for nxsem_clockwait. if you
> do not want the behavior you mentioned.
>
> Best regards,
> Chengdong
>
> <mg...@duckeck.eu> 于2026年2月20日周五 16:37写道：
>
>>
>> Hi ChengDong,
>>
>>
>> were you able to check my error message?
>> How can we solve the problem?
>>
>> BR,
>>
>> Mathias
>>
>>
>>
>>
>> chengdong wang schrieb am 06.02.2026 02:28 (GMT +01:00):
>>
>> > OK, I will take a look at this as soon as possible
>> >
>> > BR,
>> > ChengDong
>> >
>> > Alan C. Assis <ac...@gmail.com> 于2026年2月6日周五 00:50写道：
>> >
>> >> Hi Mathias,
>> >>
>> >> Thank you for finding and reporting this issue. I'm CC Chengdong here.
>> >>
>> >> Chengdong, could you please take a look at this issue?
>> >>
>> >> BR,
>> >>
>> >> Alan
>> >>
>> >> On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
>> >>
>> >> >
>> >> > Hello,
>> >> >
>> >> > I have problems with the following commit, which is part of PR #17199
>> >> >
>> >> > commit c7b6442974545b92476615ef048633609d828e5b
>> >> > Author: wangchengdong <wa...@lixiang.com>
>> >> > Date: Mon Oct 13 20:57:43 2025 +0800
>> >> > sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
>> >> >
>> >> > Improve nxclock_gettime(), to get the system time excluding
>> >> > the time that the system is suspended, when the clockid is
>> >> > CLOCK_MONOTONIC
>> >> >
>> >> > Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
>> >> >
>> >> >
>> >> >
>> >> > This commit changes the behaviour of CLOCK_MONOTONIC. It is running
>> >> slower
>> >> > than CLOCK_BOOTTIME now.
>> >> >
>> >> > I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line
>> 143
>> >> in
>> >> > nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
>> >> > CLOCK_MONOTONIC to calculate the value "abstime", but
>> wd_start_abstime()
>> >> > uses CLOCK_BOOTTIME now. When the system in running for some time this
>> >> > leads to an immediate timeout, because two different clocks are
>> compared.
>> >> >
>> >> >
>> >> > int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
>> >> > FAR const struct timespec *abstime)
>> >> > {
>> >> > ...
>> >> > if (clockid == CLOCK_REALTIME)
>> >> > {
>> >> > wd_start_realtime(&rtcb->waitdog, abstime,
>> >> > nxsem_timeout, (uintptr_t)rtcb);
>> >> > }
>> >> > else
>> >> > {
>> >> > wd_start_abstime(&rtcb->waitdog, abstime,
>> >> > nxsem_timeout, (uintptr_t)rtcb);
>> >> > }
>> >> > ...
>> >> >
>> >> >
>> >> >
>> >> > For my understanding the change of CLOCK_MONOTONIC is not correct.
>> >> > According to the POSIX definition
>> >> > https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
>> >> > "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
>> >> >
>> >> >
>> >> > On the other hand, if such a low level change is made, all usages
>> should
>> >> > be reviewed. There a lot of places where CLOCK_MONOTONIC is used in
>> the
>> >> > nuttx source code. And there are places like in nxsem_clockwait()
>> where
>> >> the
>> >> > change leads to an error even though CLOCK_MONOTONIC is not used in
>> the
>> >> > code.
>> >> >
>> >> >
>> >> > What do you think?
>> >> >
>> >> > BR,
>> >> > Mathias
>> >> >
>> >>
>> >
>>
>
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by chengdong wang <wa...@gmail.com>.
Hi Mathias,
I submitted a PR (#18437) to address the CLOCK_BOOTTIME and CLOCK_MONOTONIC
time source issue. Could you please take a look when you have a chance?
Regarding the error you mentioned, I think it should be expected behavior,
because CLOCK_MONOTONIC excludes the time the system is suspended while the
wdog for sem timeout using the time that includes the suspended period.
So my suggestion is not to use CLOCK_MONOTONIC for nxsem_clockwait. if you
do not want the behavior you mentioned.
Best regards,
Chengdong
<mg...@duckeck.eu> 于2026年2月20日周五 16:37写道：
>
> Hi ChengDong,
>
>
> were you able to check my error message?
> How can we solve the problem?
>
> BR,
>
> Mathias
>
>
>
>
> chengdong wang schrieb am 06.02.2026 02:28 (GMT +01:00):
>
> > OK, I will take a look at this as soon as possible
> >
> > BR,
> > ChengDong
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年2月6日周五 00:50写道：
> >
> >> Hi Mathias,
> >>
> >> Thank you for finding and reporting this issue. I'm CC Chengdong here.
> >>
> >> Chengdong, could you please take a look at this issue?
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
> >>
> >> >
> >> > Hello,
> >> >
> >> > I have problems with the following commit, which is part of PR #17199
> >> >
> >> > commit c7b6442974545b92476615ef048633609d828e5b
> >> > Author: wangchengdong <wa...@lixiang.com>
> >> > Date: Mon Oct 13 20:57:43 2025 +0800
> >> > sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
> >> >
> >> > Improve nxclock_gettime(), to get the system time excluding
> >> > the time that the system is suspended, when the clockid is
> >> > CLOCK_MONOTONIC
> >> >
> >> > Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
> >> >
> >> >
> >> >
> >> > This commit changes the behaviour of CLOCK_MONOTONIC. It is running
> >> slower
> >> > than CLOCK_BOOTTIME now.
> >> >
> >> > I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line
> 143
> >> in
> >> > nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
> >> > CLOCK_MONOTONIC to calculate the value "abstime", but
> wd_start_abstime()
> >> > uses CLOCK_BOOTTIME now. When the system in running for some time this
> >> > leads to an immediate timeout, because two different clocks are
> compared.
> >> >
> >> >
> >> > int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
> >> > FAR const struct timespec *abstime)
> >> > {
> >> > ...
> >> > if (clockid == CLOCK_REALTIME)
> >> > {
> >> > wd_start_realtime(&rtcb->waitdog, abstime,
> >> > nxsem_timeout, (uintptr_t)rtcb);
> >> > }
> >> > else
> >> > {
> >> > wd_start_abstime(&rtcb->waitdog, abstime,
> >> > nxsem_timeout, (uintptr_t)rtcb);
> >> > }
> >> > ...
> >> >
> >> >
> >> >
> >> > For my understanding the change of CLOCK_MONOTONIC is not correct.
> >> > According to the POSIX definition
> >> > https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
> >> > "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
> >> >
> >> >
> >> > On the other hand, if such a low level change is made, all usages
> should
> >> > be reviewed. There a lot of places where CLOCK_MONOTONIC is used in
> the
> >> > nuttx source code. And there are places like in nxsem_clockwait()
> where
> >> the
> >> > change leads to an error even though CLOCK_MONOTONIC is not used in
> the
> >> > code.
> >> >
> >> >
> >> > What do you think?
> >> >
> >> > BR,
> >> > Mathias
> >> >
> >>
> >
>
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by chengdong wang <wa...@gmail.com>.
HI Mathias
Sorry for late reply since i was on spring festival. I checked your error
message, and i agree with your point. The issue should come from that the
support of CLOCK_MONOTONIC is not sufficient.
I will provide fix for this issue as soon as possible, currently I suggest
you not using CLOCK_MONOTONIC at the moment until this issue is resolved.
BR,
Chengdong
<mg...@duckeck.eu> 于2026年2月20日周五 16:37写道：
>
> Hi ChengDong,
>
>
> were you able to check my error message?
> How can we solve the problem?
>
> BR,
>
> Mathias
>
>
>
>
> chengdong wang schrieb am 06.02.2026 02:28 (GMT +01:00):
>
> > OK, I will take a look at this as soon as possible
> >
> > BR,
> > ChengDong
> >
> > Alan C. Assis <ac...@gmail.com> 于2026年2月6日周五 00:50写道：
> >
> >> Hi Mathias,
> >>
> >> Thank you for finding and reporting this issue. I'm CC Chengdong here.
> >>
> >> Chengdong, could you please take a look at this issue?
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
> >>
> >> >
> >> > Hello,
> >> >
> >> > I have problems with the following commit, which is part of PR #17199
> >> >
> >> > commit c7b6442974545b92476615ef048633609d828e5b
> >> > Author: wangchengdong <wa...@lixiang.com>
> >> > Date: Mon Oct 13 20:57:43 2025 +0800
> >> > sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
> >> >
> >> > Improve nxclock_gettime(), to get the system time excluding
> >> > the time that the system is suspended, when the clockid is
> >> > CLOCK_MONOTONIC
> >> >
> >> > Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
> >> >
> >> >
> >> >
> >> > This commit changes the behaviour of CLOCK_MONOTONIC. It is running
> >> slower
> >> > than CLOCK_BOOTTIME now.
> >> >
> >> > I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line
> 143
> >> in
> >> > nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
> >> > CLOCK_MONOTONIC to calculate the value "abstime", but
> wd_start_abstime()
> >> > uses CLOCK_BOOTTIME now. When the system in running for some time this
> >> > leads to an immediate timeout, because two different clocks are
> compared.
> >> >
> >> >
> >> > int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
> >> > FAR const struct timespec *abstime)
> >> > {
> >> > ...
> >> > if (clockid == CLOCK_REALTIME)
> >> > {
> >> > wd_start_realtime(&rtcb->waitdog, abstime,
> >> > nxsem_timeout, (uintptr_t)rtcb);
> >> > }
> >> > else
> >> > {
> >> > wd_start_abstime(&rtcb->waitdog, abstime,
> >> > nxsem_timeout, (uintptr_t)rtcb);
> >> > }
> >> > ...
> >> >
> >> >
> >> >
> >> > For my understanding the change of CLOCK_MONOTONIC is not correct.
> >> > According to the POSIX definition
> >> > https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
> >> > "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
> >> >
> >> >
> >> > On the other hand, if such a low level change is made, all usages
> should
> >> > be reviewed. There a lot of places where CLOCK_MONOTONIC is used in
> the
> >> > nuttx source code. And there are places like in nxsem_clockwait()
> where
> >> the
> >> > change leads to an error even though CLOCK_MONOTONIC is not used in
> the
> >> > code.
> >> >
> >> >
> >> > What do you think?
> >> >
> >> > BR,
> >> > Mathias
> >> >
> >>
> >
>
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by mg...@duckeck.eu.
Hi ChengDong,
were you able to check my error message?
How can we solve the problem?
BR,
Mathias
chengdong wang schrieb am 06.02.2026 02:28 (GMT +01:00):
> OK, I will take a look at this as soon as possible
>
> BR,
> ChengDong
>
> Alan C. Assis <ac...@gmail.com> 于2026年2月6日周五 00:50写道：
>
>> Hi Mathias,
>>
>> Thank you for finding and reporting this issue. I'm CC Chengdong here.
>>
>> Chengdong, could you please take a look at this issue?
>>
>> BR,
>>
>> Alan
>>
>> On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
>>
>> >
>> > Hello,
>> >
>> > I have problems with the following commit, which is part of PR #17199
>> >
>> > commit c7b6442974545b92476615ef048633609d828e5b
>> > Author: wangchengdong <wa...@lixiang.com>
>> > Date: Mon Oct 13 20:57:43 2025 +0800
>> > sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
>> >
>> > Improve nxclock_gettime(), to get the system time excluding
>> > the time that the system is suspended, when the clockid is
>> > CLOCK_MONOTONIC
>> >
>> > Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
>> >
>> >
>> >
>> > This commit changes the behaviour of CLOCK_MONOTONIC. It is running
>> slower
>> > than CLOCK_BOOTTIME now.
>> >
>> > I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line 143
>> in
>> > nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
>> > CLOCK_MONOTONIC to calculate the value "abstime", but wd_start_abstime()
>> > uses CLOCK_BOOTTIME now. When the system in running for some time this
>> > leads to an immediate timeout, because two different clocks are compared.
>> >
>> >
>> > int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
>> > FAR const struct timespec *abstime)
>> > {
>> > ...
>> > if (clockid == CLOCK_REALTIME)
>> > {
>> > wd_start_realtime(&rtcb->waitdog, abstime,
>> > nxsem_timeout, (uintptr_t)rtcb);
>> > }
>> > else
>> > {
>> > wd_start_abstime(&rtcb->waitdog, abstime,
>> > nxsem_timeout, (uintptr_t)rtcb);
>> > }
>> > ...
>> >
>> >
>> >
>> > For my understanding the change of CLOCK_MONOTONIC is not correct.
>> > According to the POSIX definition
>> > https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
>> > "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
>> >
>> >
>> > On the other hand, if such a low level change is made, all usages should
>> > be reviewed. There a lot of places where CLOCK_MONOTONIC is used in the
>> > nuttx source code. And there are places like in nxsem_clockwait() where
>> the
>> > change leads to an error even though CLOCK_MONOTONIC is not used in the
>> > code.
>> >
>> >
>> > What do you think?
>> >
>> > BR,
>> > Mathias
>> >
>>
>
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by chengdong wang <wa...@gmail.com>.
OK, I will take a look at this as soon as possible
BR,
ChengDong
Alan C. Assis <ac...@gmail.com> 于2026年2月6日周五 00:50写道：
> Hi Mathias,
>
> Thank you for finding and reporting this issue. I'm CC Chengdong here.
>
> Chengdong, could you please take a look at this issue?
>
> BR,
>
> Alan
>
> On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
>
> >
> > Hello,
> >
> > I have problems with the following commit, which is part of PR #17199
> >
> > commit c7b6442974545b92476615ef048633609d828e5b
> > Author: wangchengdong <wa...@lixiang.com>
> > Date: Mon Oct 13 20:57:43 2025 +0800
> > sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
> >
> > Improve nxclock_gettime(), to get the system time excluding
> > the time that the system is suspended, when the clockid is
> > CLOCK_MONOTONIC
> >
> > Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
> >
> >
> >
> > This commit changes the behaviour of CLOCK_MONOTONIC. It is running
> slower
> > than CLOCK_BOOTTIME now.
> >
> > I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line 143
> in
> > nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
> > CLOCK_MONOTONIC to calculate the value "abstime", but wd_start_abstime()
> > uses CLOCK_BOOTTIME now. When the system in running for some time this
> > leads to an immediate timeout, because two different clocks are compared.
> >
> >
> > int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
> > FAR const struct timespec *abstime)
> > {
> > ...
> > if (clockid == CLOCK_REALTIME)
> > {
> > wd_start_realtime(&rtcb->waitdog, abstime,
> > nxsem_timeout, (uintptr_t)rtcb);
> > }
> > else
> > {
> > wd_start_abstime(&rtcb->waitdog, abstime,
> > nxsem_timeout, (uintptr_t)rtcb);
> > }
> > ...
> >
> >
> >
> > For my understanding the change of CLOCK_MONOTONIC is not correct.
> > According to the POSIX definition
> > https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
> > "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
> >
> >
> > On the other hand, if such a low level change is made, all usages should
> > be reviewed. There a lot of places where CLOCK_MONOTONIC is used in the
> > nuttx source code. And there are places like in nxsem_clockwait() where
> the
> > change leads to an error even though CLOCK_MONOTONIC is not used in the
> > code.
> >
> >
> > What do you think?
> >
> > BR,
> > Mathias
> >
>
Re: Bug in sem_clockwait() due to change of CLOCK_MONOTONIC
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Mathias,
Thank you for finding and reporting this issue. I'm CC Chengdong here.
Chengdong, could you please take a look at this issue?
BR,
Alan
On Thu, Feb 5, 2026 at 12:32 PM <mg...@duckeck.eu> wrote:
>
> Hello,
>
> I have problems with the following commit, which is part of PR #17199
>
> commit c7b6442974545b92476615ef048633609d828e5b
> Author: wangchengdong <wa...@lixiang.com>
> Date: Mon Oct 13 20:57:43 2025 +0800
> sched/clock: Improve CLOCK_MONOTONIC nxclock_gettime()
>
> Improve nxclock_gettime(), to get the system time excluding
> the time that the system is suspended, when the clockid is
> CLOCK_MONOTONIC
>
> Signed-off-by: Chengdong Wang wangchengdong@lixiang.com
>
>
>
> This commit changes the behaviour of CLOCK_MONOTONIC. It is running slower
> than CLOCK_BOOTTIME now.
>
> I called sem_clockwait() with CLOCK_MONOTONIC, but the "if" in line 143 in
> nuttx/sched/semaphore/sem_clockwait.c handles on two cases. I used
> CLOCK_MONOTONIC to calculate the value "abstime", but wd_start_abstime()
> uses CLOCK_BOOTTIME now. When the system in running for some time this
> leads to an immediate timeout, because two different clocks are compared.
>
>
> int nxsem_clockwait(FAR sem_t *sem, clockid_t clockid,
> FAR const struct timespec *abstime)
> {
> ...
> if (clockid == CLOCK_REALTIME)
> {
> wd_start_realtime(&rtcb->waitdog, abstime,
> nxsem_timeout, (uintptr_t)rtcb);
> }
> else
> {
> wd_start_abstime(&rtcb->waitdog, abstime,
> nxsem_timeout, (uintptr_t)rtcb);
> }
> ...
>
>
>
> For my understanding the change of CLOCK_MONOTONIC is not correct.
> According to the POSIX definition
> https://pubs.opengroup.org/onlinepubs/9799919799/ it must be a
> "system-wide monotonic clock", CLOCK_BOOTTIME is not defined here.
>
>
> On the other hand, if such a low level change is made, all usages should
> be reviewed. There a lot of places where CLOCK_MONOTONIC is used in the
> nuttx source code. And there are places like in nxsem_clockwait() where the
> change leads to an error even though CLOCK_MONOTONIC is not used in the
> code.
>
>
> What do you think?
>
> BR,
> Mathias
>