Re: Kernel MS Precision
Benjamin Walsh <benjamin.walsh@...>
On Thu, Mar 23, 2017 at 03:40:42PM +0000, Rosen, Michael R wrote:
ns or us, you still needed 64-bit timeouts for either, which ended upHowever, having timeouts as int32_t instead of uint32_t, there is nothingWhile Im not sure Im 100% convinced, having negative numbers just be
being the major concern. 64-bit math can be costly: we've seen stack
usage increase of 80 bytes on some architectures. Also, I don't think
2000s is enough for a maximum timeout, with us resolution and signed
Though at the same time, if users are expected to use the macros, whyI think ms is the unit most users will use, and that one does not always
need a macro.
I don't remember why we added K_MSEC(), maybe to round up the API
with K_SECONDS, etc.
The users can decide to use the macros or not.
Do you prefer
Which one is less confusing or error-prone ?
is perfectly readable.
for timers/timeouts and ticks are user configurable, why hold the APIBecause we wanted to go to a tickless kernel, so we wanted to have the
API use common time units instead of ticks.
This was covered in the unified kernel RFC. You can search the mailing
list of still find an early version here:
It's still pretty accurate, but it's missing the ms timeouts discussion,
since we decided not to use gerrit to handle RFCs after this was
published, and thus never updated.
My take on this is that there is a way forward that is
backwards-compatible with the current API. It should probably be
configurable, since the timeout code will take hit to handle the two
That work can be turned into a Jira and prioritized if deemed important
enough, and it seems it is, for you at least, which means that probably
other people will hit the same issue.