That said, we are off by 34 nanoseconds. Not sure that is a strict requirement to have the alarm be triggered by not more than the value given. But this is so close, I would hardly designate it as a bug. Add to it that this is using ABSTIME. There could be a hidden bug here, but I would bet this is not a regression and it hardly matters much. And it is not anyone of the two commits referred by the test.
The reading back of the timer seems relatively recent.
commit b34e243e85dde08 9dbb84dd6d63dc0 fe95b4d504
Author: Viresh Kumar <email address hidden>
Date: Wed Jul 8 16:01:04 2020 +0530
syscalls/ timer_settime01 : Make sure the timer fires
This patch improves the testcase by doing multiple things:
- Make sure the timer fires and catch the signals.
- Verify the values set to the itimerspec by reading them again using gettime( ) syscalls.
timer_
- Reduce the timer interval, 5 seconds was way too much.
Signed-off-by: Viresh Kumar <email address hidden>
Signed-off-by: Cyril Hrubis <email address hidden>
That said, we are off by 34 nanoseconds. Not sure that is a strict requirement to have the alarm be triggered by not more than the value given. But this is so close, I would hardly designate it as a bug. Add to it that this is using ABSTIME. There could be a hidden bug here, but I would bet this is not a regression and it hardly matters much. And it is not anyone of the two commits referred by the test.
Cascardo.