Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Christian, On Mon, 2022-08-01 at 20:32 +0200, o...@c-mauderer.de wrote: > Hello Duc, > > Am 01.08.22 um 04:13 schrieb Duc Doan: > > Hello Christian, > > > > On Sun, 2022-07-31 at 20:01 +0200, o...@c-mauderer.de wrote: > > > Hello Duc, > > > > > > Am 31.07.22 um 17:07 schrieb Duc Doan: > > > > Hello Christian, > > > > > > > > On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote: > > > > > Hello Duc, > > > > > > > > > > general note for the patch: Please write in the commit > > > > > message > > > > > where > > > > > you > > > > > got the sources from. That can be a link to a github repo > > > > > including a > > > > > commit ID or a link to the zip file from ST (including a > > > > > date, > > > > > version > > > > > or similar information). If you moved some stuff around > > > > > compared > > > > > to > > > > > the > > > > > original structure: Please describe about what you did. For > > > > > example > > > > > in > > > > > the imxrt I just added the cp commands that I used: > > > > > > > > > > > > > > > https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 > > > > > > > > > > Not the best solution but at least someone else can find out > > > > > roughly > > > > > what I did. > > > > > > > > > > > > > Ah yes, I will do that. I thought I only needed to put the > > > > description > > > > in the email before. > > > > > > > > > Am 24.07.22 um 14:01 schrieb Duc Doan: > > > > > > This patch is too large so I cannot send via email. Please > > > > > > find > > > > > > it > > > > > > here: > > > > > > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 > > > > > > > > > > > > --- > > > > > > .gitignore | 1 + > > > > > > > > > > You added a "patches" directory to the gitignore. That looks > > > > > like > > > > > a > > > > > change that is specific to your method of working. These kind > > > > > of > > > > > changes > > > > > should normall not be pushed. > > > > > > > > > > If you want to ignore stuff specific to your work > > > > > environment, I > > > > > recommend to use a global .gitignore file. Git has a > > > > > "core.excludesfile" > > > > > config for that. > > > > > > > > > > > > > Thanks for the suggestion, I will fix that. > > > > > > > > > > bsps/arm/include/cmsis_compiler.h | 266 + > > > > > > bsps/arm/include/cmsis_gcc.h | 3460 > > > > > > +-- > > > > > > bsps/arm/include/cmsis_version.h | 39 + > > > > > > bsps/arm/include/core_cm4.h | 524 > > > > > > +- > > > > > > bsps/arm/include/core_cm7.h | 5186 > > > > > > ++-- > > > > > > bsps/arm/include/mpu_armv7.h | 270 + > > > > > > > > > > Are the cmsis files from the same source or directly from > > > > > ARM? > > > > > > > > > > > > > They are from the same source (STM HAL v1.27.1). > > > > > > > > > The cmsis_gcc.h has a lot of changes compared to the earlier > > > > > version > > > > > that has been present in RTEMS. A lot of the changes seem to > > > > > be > > > > > whitespace changes. Can these be avoided somehow (for example > > > > > by > > > > > using > > > > > dos2unix before overwriting the file)? > > > > > > > > > > > > > From what I've just read about dos2unix, it converts line > > > > breaks > > > > from > > > > CRLF to LF (please correct me if I'm wrong). How will this > > > > command > > > > resolve the whitespace changes? > > > > > > I haven't looked at the exact type of whitespace changes. I had > > > the > > > impression that the difference is most likely only the line > > > ending. > > > It > > > didn't look like tab / space issue. Is it a tab / space issue? > > > > > > > I've looked at the some files and noticed that the difference is > > mostly > > additional code/code change (e.g. adding support for ARMv8), but > > not > > whitespace changes. > > > > Hm. Odd. In that case: Why does the diff show a complete removal and > complete adding of (for example) cmsis_gcc.h: > > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 > > I'm not sure why that happens. I used this page to compare line-by- line: https://www.diffchecker.com/xMCBtxbt This is the diff for cmsis_gcc. Best, Duc > > > > > > > > > In the discord chat there was one suggestion from Ho Kaido to > > > > > move > > > > > the > > > > > files one level down and make them BSP specific. I'm not sure > > > > > whether > > > > > I'm for or against that idea. Advantage is that it makes BSPs > > > > > independant from each other. Disadvantage is that it > > > > > duplicates > > > > > code. > > > > > > > > > > I think I would try to avoid moving them down due to the code > > > > > duplication but it raises the question: Which BSPs use the > > > > > files > > > > > too > >
[PATCH] testsuite/psxclock: Check setting realtime clock does not effect sleeping tasks
From: Chris Johns
Closes #4690
---
testsuites/psxtests/psxclock/init.c | 172 +++-
1 file changed, 171 insertions(+), 1 deletion(-)
diff --git a/testsuites/psxtests/psxclock/init.c
b/testsuites/psxtests/psxclock/init.c
index 2300056f61..743cfa6d78 100644
--- a/testsuites/psxtests/psxclock/init.c
+++ b/testsuites/psxtests/psxclock/init.c
@@ -50,6 +50,174 @@ static void check_enosys(int status)
rtems_test_exit(0);
}
+static void wait_ticks( rtems_interval ticks )
+{
+ /*
+ * Avoid any clock related sleep calls
+ */
+ rtems_test_assert( rtems_task_wake_after( ticks ) == RTEMS_SUCCESSFUL );
+}
+
+struct clock_context;
+typedef struct clock_context clock_context;
+typedef void (*clock_sleeper)(clock_context* ctx);
+struct clock_context {
+ const char* name;
+ int instance;
+ rtems_id tid;
+ int counter;
+ int result;
+ rtems_interval ticks;
+ struct timespec tspec;
+ clock_sleeper sleeper;
+};
+
+static void clock_context_init(
+ clock_context* ctx, const char* name, int instance,
+ time_t secs, long nsecs, clock_sleeper sleeper)
+{
+ memset( ctx, 0, sizeof( *ctx ) );
+ ctx->name = name;
+ ctx->instance = instance;
+ ctx->tspec.tv_sec = secs;
+ ctx->tspec.tv_nsec = nsecs;
+ ctx->sleeper = sleeper;
+}
+
+static void test_nanosleep( clock_context* ctx )
+{
+ if ( nanosleep ( >tspec, NULL ) < 0 )
+ {
+ctx->result = errno;
+ }
+}
+
+static void test_clock_nanosleep_realtime( clock_context* ctx )
+{
+ if ( clock_nanosleep ( CLOCK_REALTIME, 0, >tspec, NULL ) < 0 )
+ {
+ctx->result = errno;
+ }
+}
+
+static void test_clock_nanosleep_monotonic( clock_context* ctx )
+{
+ if ( clock_nanosleep ( CLOCK_MONOTONIC, 0, >tspec, NULL ) < 0 )
+ {
+ctx->result = errno;
+ }
+}
+
+static void test_clock_check( clock_context* ctx, const rtems_interval
ticks_per_sec )
+{
+ const long tick_period_nsec = 10LLU / ticks_per_sec;
+ rtems_interval ticks =
+(((ctx->tspec.tv_sec * 10LLU) + ctx->tspec.tv_nsec) /
tick_period_nsec) + 1;
+ rtems_test_assert( ctx->result == 0 );
+ printf(
+"clock: %s: sec=%llu nsec=%li ticks=%u expected-ticks=%u\n",
+ctx->name, ctx->tspec.tv_sec, ctx->tspec.tv_nsec, ctx->ticks, ticks);
+ rtems_test_assert( ctx->ticks == ticks );
+}
+
+static void task_clock( rtems_task_argument arg )
+{
+ clock_context* ctx = (clock_context*) arg;
+ rtems_interval start = rtems_clock_get_ticks_since_boot();
+ rtems_interval end;
+ ctx->result = 0;
+ ctx->sleeper( ctx );
+ end = rtems_clock_get_ticks_since_boot();
+ ctx->ticks = end - start;
+ ++ctx->counter;
+ rtems_task_delete( RTEMS_SELF );
+}
+
+static void test_start_task( clock_context* ctx )
+{
+ rtems_status_code sc;
+ sc = rtems_task_create(
+rtems_build_name( 'C', 'R', 'T', '0' + ctx->instance ),
+1,
+RTEMS_MINIMUM_STACK_SIZE,
+RTEMS_DEFAULT_MODES,
+RTEMS_DEFAULT_ATTRIBUTES,
+>tid
+ );
+ rtems_test_assert( sc == RTEMS_SUCCESSFUL );
+ sc = rtems_task_start( ctx->tid, task_clock, (rtems_task_argument) ctx );
+ rtems_test_assert( sc == RTEMS_SUCCESSFUL );
+}
+
+static void test_settime_and_sleeping_step( int step )
+{
+ const rtems_interval ticks_per_sec = rtems_clock_get_ticks_per_second();
+ struct timespec tv;
+
+ clock_context ns_ctx;
+ clock_context cnr_ctx;
+ clock_context cnm_ctx;
+
+ printf( "\nClock settime while sleeping: step=%i\n", step );
+
+ clock_context_init(
+_ctx, "nanosleep", 0, 0, 5,
+test_nanosleep );
+ clock_context_init(
+_ctx, "clock_nanosleep(CLOCK_REALTIME)", 0, 0, 5,
+test_clock_nanosleep_realtime );
+ clock_context_init(
+_ctx, "clock_nanosleep(CLOCK_MONOTONIC)", 0, 0, 5,
+test_clock_nanosleep_monotonic );
+
+ /* Sat, 01 Jan 2000 00:00:00 GMT */
+ tv.tv_sec = 946684800;
+ tv.tv_nsec = 0;
+ rtems_test_assert( clock_settime( CLOCK_REALTIME, ) == 0 );
+
+ wait_ticks( 1 );
+
+ test_start_task( _ctx );
+ test_start_task( _ctx );
+ test_start_task( _ctx );
+
+ wait_ticks( 2 );
+
+ /*
+ * Jump forwards 1 second
+ */
+ if ( step != 0 )
+ {
+tv.tv_sec = 946684800 + step;
+tv.tv_nsec = 0;
+rtems_test_assert( clock_settime( CLOCK_REALTIME, ) == 0 );
+ }
+
+ while (true)
+ {
+int counts = 0;
+wait_ticks( ticks_per_sec / 4 );
+counts += ns_ctx.counter;
+counts += cnr_ctx.counter;
+counts += cnm_ctx.counter;
+if (counts == 3)
+{
+ break;
+}
+ }
+
+ test_clock_check( _ctx, ticks_per_sec );
+ test_clock_check( _ctx, ticks_per_sec );
+ test_clock_check( _ctx, ticks_per_sec );
+}
+
+static void test_settime_and_sleeping( void )
+{
+ test_settime_and_sleeping_step( 0 );
+ test_settime_and_sleeping_step( 1 );
+ test_settime_and_sleeping_step( -1 );
+}
+
typedef struct {
int counter;
struct timespec delta;
@@ -358,6 +526,8 @@ static rtems_task Init(
}
#endif
+ test_settime_and_sleeping( );
+
TEST_END();
rtems_test_exit(0);
}
@@ -370,7 +540,7 @@ static
[PATCH] testsuite/psxclock: Check setting realtime clock
Hi This patch adds a test to make sure threads sleeping on a clock_nanosleep(CLOCK_REALTIME) call are not effected by a change in the realtime clock via the clock_settime(CLOCK_REALTIME). The tests checks the sleeping thread's period using clock ticks. I have checked the test and Sebastian's patch on: arm/xilinx_zynq_a9_qemu sparc/erc32 aarch64/xilinx_zynqmp_lp64_zu3eg Chris In-Reply-To: ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] posix: Fix relative CLOCK_REALTIME sleep
On 1/8/2022 6:52 pm, Sebastian Huber wrote: > On 01/08/2022 10:48, Chris Johns wrote: >> On 1/8/2022 6:20 pm, Sebastian Huber wrote: >>> On 01/08/2022 10:16, Chris Johns wrote: On 1/8/2022 5:22 pm, Sebastian Huber wrote: > A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME > changes through clock_settime(). Since our CLOCK_REALTIME is basically > just > CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC > watchdog > for relative CLOCK_REALTIME time outs. Thank for this. I can confirm it works with the modified test code I attached to the ticket. I am ts-validation-no-clock-0.exe now failing on xilinx_zynq_a9_qemu but I am not sure? >>> I have to adjust the ts-validation-no-clock-0.exe if we want to fix the >>> issue >>> like this. >>> There is one issue my test changes have exposed and that is the ticks a thread sleeps for is 1 more than the requested number. >>> I think this is the expected behaviour. You should sleep at least the >>> requested >>> amount of time. >> I am using 500msec so I would expect the result to be exact? If it was >> 501msec >> then I would agree. > > What do you mean with exact? If you want to wait for 500ms, then you will wake > up in 500ms plus one clock tick interval (unless you measure the start time > exactly at the clock tick event which is very unlikely). Yeap I agree after looking at this again. You have to account for the extra tick. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Duc, Am 01.08.22 um 04:13 schrieb Duc Doan: Hello Christian, On Sun, 2022-07-31 at 20:01 +0200, o...@c-mauderer.de wrote: Hello Duc, Am 31.07.22 um 17:07 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote: Hello Duc, general note for the patch: Please write in the commit message where you got the sources from. That can be a link to a github repo including a commit ID or a link to the zip file from ST (including a date, version or similar information). If you moved some stuff around compared to the original structure: Please describe about what you did. For example in the imxrt I just added the cp commands that I used: https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 Not the best solution but at least someone else can find out roughly what I did. Ah yes, I will do that. I thought I only needed to put the description in the email before. Am 24.07.22 um 14:01 schrieb Duc Doan: This patch is too large so I cannot send via email. Please find it here: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 --- .gitignore | 1 + You added a "patches" directory to the gitignore. That looks like a change that is specific to your method of working. These kind of changes should normall not be pushed. If you want to ignore stuff specific to your work environment, I recommend to use a global .gitignore file. Git has a "core.excludesfile" config for that. Thanks for the suggestion, I will fix that. bsps/arm/include/cmsis_compiler.h | 266 + bsps/arm/include/cmsis_gcc.h | 3460 +-- bsps/arm/include/cmsis_version.h | 39 + bsps/arm/include/core_cm4.h | 524 +- bsps/arm/include/core_cm7.h | 5186 ++-- bsps/arm/include/mpu_armv7.h | 270 + Are the cmsis files from the same source or directly from ARM? They are from the same source (STM HAL v1.27.1). The cmsis_gcc.h has a lot of changes compared to the earlier version that has been present in RTEMS. A lot of the changes seem to be whitespace changes. Can these be avoided somehow (for example by using dos2unix before overwriting the file)? From what I've just read about dos2unix, it converts line breaks from CRLF to LF (please correct me if I'm wrong). How will this command resolve the whitespace changes? I haven't looked at the exact type of whitespace changes. I had the impression that the difference is most likely only the line ending. It didn't look like tab / space issue. Is it a tab / space issue? I've looked at the some files and noticed that the difference is mostly additional code/code change (e.g. adding support for ARMv8), but not whitespace changes. Hm. Odd. In that case: Why does the diff show a complete removal and complete adding of (for example) cmsis_gcc.h: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 In the discord chat there was one suggestion from Ho Kaido to move the files one level down and make them BSP specific. I'm not sure whether I'm for or against that idea. Advantage is that it makes BSPs independant from each other. Disadvantage is that it duplicates code. I think I would try to avoid moving them down due to the code duplication but it raises the question: Which BSPs use the files too and did you try whether they still compile after the upgrade? Until now I only know of STM32H7 BSP that is using the CMSIS files. I tried compiling it before and Karel also confirmed that the BSP compiles. Just as an example: core_cm4/7.h is included at least in stm32f4, stm32h7, atsam and imxrt. So we have to make sure that these three are compile-clean. Please use grep to find out where the headers are included and check whether I maybe missed a BSP. I have checked using grep (grep -rl ~/gsoc2022/src/rtems/bsps/arm -e "cmsis\|core_cm" and found that stm32f4, imxrt, stm32h7, and atsam are using CMSIS files (you remembered all correctly!). I've checked and all 4 of them compile without error. Great. Thanks for checking. Best regards Christian Best, Duc .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c | 1679 ++ .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c | 2307 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal.c | 615 + bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c | 2110 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c | 1112 + bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c | 2462 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c | 996 + bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c | 502 + bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c | 328 + bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c | 7132 ++
Re: [PATCH] posix: Fix relative CLOCK_REALTIME sleep
On 01/08/2022 10:48, Chris Johns wrote: On 1/8/2022 6:20 pm, Sebastian Huber wrote: On 01/08/2022 10:16, Chris Johns wrote: On 1/8/2022 5:22 pm, Sebastian Huber wrote: A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME changes through clock_settime(). Since our CLOCK_REALTIME is basically just CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog for relative CLOCK_REALTIME time outs. Thank for this. I can confirm it works with the modified test code I attached to the ticket. I am ts-validation-no-clock-0.exe now failing on xilinx_zynq_a9_qemu but I am not sure? I have to adjust the ts-validation-no-clock-0.exe if we want to fix the issue like this. There is one issue my test changes have exposed and that is the ticks a thread sleeps for is 1 more than the requested number. I think this is the expected behaviour. You should sleep at least the requested amount of time. I am using 500msec so I would expect the result to be exact? If it was 501msec then I would agree. What do you mean with exact? If you want to wait for 500ms, then you will wake up in 500ms plus one clock tick interval (unless you measure the start time exactly at the clock tick event which is very unlikely). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] posix: Fix relative CLOCK_REALTIME sleep
On 1/8/2022 6:20 pm, Sebastian Huber wrote: > On 01/08/2022 10:16, Chris Johns wrote: >> On 1/8/2022 5:22 pm, Sebastian Huber wrote: >>> A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME >>> changes through clock_settime(). Since our CLOCK_REALTIME is basically just >>> CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC >>> watchdog >>> for relative CLOCK_REALTIME time outs. >> Thank for this. I can confirm it works with the modified test code I >> attached to >> the ticket. I am ts-validation-no-clock-0.exe now failing on >> xilinx_zynq_a9_qemu >> but I am not sure? > > I have to adjust the ts-validation-no-clock-0.exe if we want to fix the issue > like this. > >> >> There is one issue my test changes have exposed and that is the ticks a >> thread >> sleeps for is 1 more than the requested number. > > I think this is the expected behaviour. You should sleep at least the > requested > amount of time. I am using 500msec so I would expect the result to be exact? If it was 501msec then I would agree. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] posix: Fix relative CLOCK_REALTIME sleep
On 01/08/2022 10:16, Chris Johns wrote: On 1/8/2022 5:22 pm, Sebastian Huber wrote: A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME changes through clock_settime(). Since our CLOCK_REALTIME is basically just CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog for relative CLOCK_REALTIME time outs. Thank for this. I can confirm it works with the modified test code I attached to the ticket. I am ts-validation-no-clock-0.exe now failing on xilinx_zynq_a9_qemu but I am not sure? I have to adjust the ts-validation-no-clock-0.exe if we want to fix the issue like this. There is one issue my test changes have exposed and that is the ticks a thread sleeps for is 1 more than the requested number. I think this is the expected behaviour. You should sleep at least the requested amount of time. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] posix: Fix relative CLOCK_REALTIME sleep
On 1/8/2022 5:22 pm, Sebastian Huber wrote: > A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME > changes through clock_settime(). Since our CLOCK_REALTIME is basically just > CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog > for relative CLOCK_REALTIME time outs. Thank for this. I can confirm it works with the modified test code I attached to the ticket. I am ts-validation-no-clock-0.exe now failing on xilinx_zynq_a9_qemu but I am not sure? There is one issue my test changes have exposed and that is the ticks a thread sleeps for is 1 more than the requested number. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] posix: Fix relative CLOCK_REALTIME sleep
A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME
changes through clock_settime(). Since our CLOCK_REALTIME is basically just
CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog
for relative CLOCK_REALTIME time outs.
Update #4690.
---
cpukit/posix/src/clocknanosleep.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/cpukit/posix/src/clocknanosleep.c
b/cpukit/posix/src/clocknanosleep.c
index 3fa890fecd..bfa8ef7975 100644
--- a/cpukit/posix/src/clocknanosleep.c
+++ b/cpukit/posix/src/clocknanosleep.c
@@ -82,6 +82,15 @@ int clock_nanosleep(
rmtp = NULL;
} else {
absolute = false;
+
+/*
+ * A relative CLOCK_REALTIME time out shall not be affected by
+ * CLOCK_REALTIME changes through clock_settime(). Since our
+ * CLOCK_REALTIME is basically just CLOCK_MONOTONIC plus an offset, we can
+ * simply use the CLOCK_MONOTONIC watchdog for relative CLOCK_REALTIME time
+ * outs.
+ */
+clock_id = CLOCK_MONOTONIC;
}
if ( clock_id == CLOCK_REALTIME ) {
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
