sys/xtimer: deprecate for 2023.04#18560
Conversation
Now that we have ztimer running on all RIOT applications we should simplify and only use ztimer.
|
This was done in the General Assembly while talking about deprecation. I am sure we all wanted this... |
|
When I have time I think I will swap all the xtimer APIs out from the examples. |
|
I think the xtimer compat header could be kept and used as a convenience API (see #17330) for code that should work no matter if ZTIMER_MSEC, ZTIMER_USEC or some other future ztimer backend is compiled in. e.g. |
|
Does it make sense to add the notice separate from the swapping of the API? I feel like it would be nice to get this in the release and I don't know how long it will take me to swap all the xtimer stuff we have. |
I haven't looked into it but one reason I really want to get rid of xtimer is to make it easier to model. If it is a simple thing, then sure that makes sense. If it is one of those things that only recursive make + luck to not hit a race condition can solve than I may push back. |
|
We should come to a conclusion before the release. Can we deprecate while still having |
Contribution description
Now that we have ztimer running on all RIOT applications we should simplify
and only use ztimer.
Testing procedure
Read the docs? Check to see if you have a message in the
make -C tests.Issues/PRs references