Skip to content

sys/xtimer: deprecate for 2023.04#18560

Open
MrKevinWeiss wants to merge 1 commit intoRIOT-OS:masterfrom
MrKevinWeiss:pr/deprecatextimer
Open

sys/xtimer: deprecate for 2023.04#18560
MrKevinWeiss wants to merge 1 commit intoRIOT-OS:masterfrom
MrKevinWeiss:pr/deprecatextimer

Conversation

@MrKevinWeiss
Copy link
Copy Markdown
Contributor

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

Now that we have ztimer running on all RIOT applications we should simplify
and only use ztimer.
@github-actions github-actions bot added Area: build system Area: Build system Area: sys Area: System Area: timers Area: timer subsystems labels Sep 6, 2022
@MrKevinWeiss
Copy link
Copy Markdown
Contributor Author

This was done in the General Assembly while talking about deprecation. I am sure we all wanted this...

@MrKevinWeiss
Copy link
Copy Markdown
Contributor Author

When I have time I think I will swap all the xtimer APIs out from the examples.

@benpicco
Copy link
Copy Markdown
Contributor

benpicco commented Sep 6, 2022

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. xtimer_msleep(10) will use ztimer_sleep(ZTIMER_MSEC, 10) if ztimer_msec is used, but will gracefully degrade into ztimer_sleep(ZTIMER_USEC, 10000) if that is not the case.

@MrKevinWeiss
Copy link
Copy Markdown
Contributor Author

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.

@MrKevinWeiss
Copy link
Copy Markdown
Contributor Author

I think the xtimer compat header could be kept and used as a convenience API

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.

@MrKevinWeiss
Copy link
Copy Markdown
Contributor Author

We should come to a conclusion before the release.

Can we deprecate while still having USEMODULE += xtimer in the repo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: build system Area: Build system Area: sys Area: System Area: timers Area: timer subsystems

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants