-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkg/tinydtls: migrate to ztimer64_msec #17564
pkg/tinydtls: migrate to ztimer64_msec #17564
Conversation
The
|
I would merge this PR with the patch and then PR the patch upstream, and then in another PR remove the patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at first glance this does not need ztimer64_usec
but should use ztimer_msec
} | ||
|
||
void | ||
dtls_ticks(dtls_tick_t *t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the upstream default configuration this provides msec ticks
maybe the whole package can use ztimer msec
for contiki the dtls_tick_t is uint_32
seems like there might be no need for ztimer64
at least not for ztimer64_usec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean ztimer64_msec
then? Because I'm a bit worried about the rollover with 32bit msec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tinydtls people are not concerned over the 32Bit msec (at least in the contiki case) i don't see time beeing part of the messages of rfc4347 and all timout are in the range of a couple of seconds -> why go 64 bit.
If tinydtls would have a problem going with 32Bit msecs this would be a bug in tinydtls which should also be fixed in interest of contiki.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall I squash @kfessel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kfessel since eclipse/tinydtls#123 (comment) It makes me thinks in a first stage its better to leave it in ms, what about ztimer64_msec
, as a first step, once questions in eclipse/tinydtls#123 (comment) are clarified maybe we can remove the 64bit part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for that late answer:
we can certainly go that route i think they will sort that out and i am much less against ztimer64_msec use (than zt64us)
they also will sort out eclipse/tinydtls#124
Ok, changed to use
|
43ad1c7
to
e6822e0
Compare
I switched to ztimer64_msec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a simple direct replacement, the author ran the tests. (documented above)
Re-tested, all OK!, Go! |
Thanks @kfessel! |
Do we really need ztimer64 here? |
Upstream had or has some 32 bit time-overflow problem (it is most likely fixed with eclipse/tinydtls#131). But upstream seems to be not sure eclipse/tinydtls#125 until a unit-test for the overflow exists. I am not sure if we want to go 32 Bit or wait until upstream is sure. |
But upstream doesn't even use ztimer64: dtls_time.c#L44 |
Contribution description
tinydtls
is usins somextimer
externals which prevent a drop in replacement withztimer_xtimer_compat
, so this PR migrate it to useztimer64_msec
instead ofxtimer
.The patch would be upstreamed later, but I think it makes more sense to get it reviewed here first.
Testing procedure
Issues/PRs references
Split form #17365