sys/ztimer: Remove the deprecated ztimer_now64 #20826
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This has been scheduled for removal after 2022.10, and its replacement ztimer64_now has long been available.
chrysn
requested review from
leandrolanzieri,
aabadie,
MichelRottleuthner and
bergzand
as code owners
github-actions
bot
added
Area: doc
chrysn
added
CI: ready for build
maribu
approved these changes
Aug 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removal has been scheduled for removal after 2022.10, and its replacement ztimer64_now has long been available.
This was done with little knowledge of how ztimer_now64 actually worked: I effectively grepped for /ztimer.now64/i, changed the code to what it would have been if MODULE_ZTIMER_NOW64 had never been there, and removed the various references to things that are different when it was active.
I've left the ztimer_now_t in place, but documented it to be uint32_t unconditionally. I think it is a practical choice to have semantic type aliases even when they are constant, but if reviewers prefer, I can just as well remove or deprecated that type (but it was not deprecated, so we better at least leave it deprecated).
Testing procedure
Issues/PRs references
I found that this was still around updating the Rust wrappers for ztimer -- nothing that needed much special care, but the conversion path from ztimer_now_t to u32 where ztimer_now_t is larger would have effectively never been tested.