RFC: rework of high resolution timer, sleep, and posix clock APIs and subsystems #40099
Labels
area: Kernel
area: POSIX
POSIX API Library
area: Timer
Timer
RFC
Request For Comments: want input from the community
I wanted to reintroduce discussion of a topic that is quite important - namely, HR timer support, improved support for e.g.
nanosleep(2)
and POSIX clock APIs such asclock_getres(3)
,clock_gettime(3)
, et al. This could all probably be collectively defined as "Real Time".This has been on the agenda for a fairly long time. See e.g. #6498, #19030, #19282, #28542. @pabigot put a lot of effort into moving this forward and I promised that I would help to push it forward as well. I was reminded to start this conversation again with #35703.
Tagging others (please feel free to edit): @cvinayak, @nordic-krch, @andyross, @nashif, @pfalcon, @carlescufi, @stephanosio
I would also like to volunteer to drive most of this work until it is finished, and ideally that would be in v3.0.0. I am fairly fluent in the language of RT but am by no means an expert in all of its nuances in Zephyr, which is why i think it's critical to ensure that we do bring together the right people in this discussion and come to a general consensus before any work is started. Also, let's not be standoffish or judgemental - we're all hoping to improve the current state of timekeeping in Zephyr and the best way to achieve that is through collaboration.
Feel free to edit the topic as needed.
Similar to what was proposed in #19030, I would like to second that we support a number of standard clock sources and mimic the POSIX model. This will simplify testing. We need internal API for managing a collection of clock sources and timers (ideally this would be compile-time const for the most part and involve DT).
While working on
nanosleep(2)
, it became quite evident that busy-waiting is not the best way to achieve accurate delays and that we need to have assistance from hardware - but it should be done in a vendor-neutral way.The system timer in Zephyr often does not use the highest-res clock source. Some clocks may not have a common source, and can exhibit drift w.r.t. one another even on the same SoC.
Have to run atm, but I just wanted to jot down some notes here. Please feel free to add to this. No rush either - focus will be after v2.7.0 is released.
The text was updated successfully, but these errors were encountered: