On 9 Sep 2025, at 02:48, Anna Lyons <pingerino@gmail.com> wrote:
Hey look, I can participate in the TSC!
Great to have you back! :-)
I did consider this when building the api. There were two reasons against it:
1. a painful api (most user-apps want ticks) - but this could always be pushed into libsel4 where one has the advantage of an FPU/being able to use a divisor - specific users could also determine their own accuracy/precision trade offs
Yes, my proposal would be to at least provide a libsel4 layer that is still in time_t. I’m not quite clear on whether the change should be invisible, i.e. ticks_t API with a new name, time_t API with the old name, or if we should explicitly make it breaking. I don’t see a good reason to make it breaking, so my default would be not to.
2. as Gernot mentioned in the thread, clock rate changes could be a concern - this was the deciding factor
I believe as long as the kernel timer is independent of the CPU frequency due to scaling (which IIRC is the case for the arm generic timers which these days are thankfully the norm, unlike earlier hardware) changing to ticks shouldn't be an issue, and will remove a lot of painful logic in the kernel. Would be worth confirming this on supported hardware.
Ok, we should definitely confirm, would be good to document. The current API does assume the timer frequency to be a compile time constant in the kernel, but if we are planning to work with frequency scaling, now would be the time to think about that. Cheers, Gerwin