Brad Campbell

Ok the last piece on the build side is the controversial #383. That will enable the libraries to automatically compile when trying to compile the app.

> @bradjc does the revised libtock build system support this now? > > > I think we should create a new helper makefile in libtock-c/openthread that apps can include which...

Unfortunately we did not include this when working on the libtock-c rewrite. If anyone has ideas on how this support should be structured please suggest.

> Can we convert this to a regular PR for using yield_wait_for in console? I'm concerned about repeating the original libtock-c mistakes, ie everyone implements drivers with `yield_wait_for` in whatever...

> e.g. you wouldn't be able to have both many outstanding alarms and do a synchronous `sleep` Wait, what happens if you try this? It seems like things would break...

It seems like realistically this is only going to be an issue with anything where there is a long-running outstanding operation (essentially an interrupt). Examples that come to mind: -...

I think the expectation for `delay_ms()` is that everything stops and blocks until that many ms have elapsed. To implement this, I think we need to re-implement `delay_ms()` to not...

What is left to do here? Move code from openthread to the general alarm code?

@hudson-ayers Do you think there is any reason to keep the `libtock_alarm_repeating_t` type around? It would essentially be an alias for `libtock_alarm_t` right now, but if we need to keep...

Can I ask you follow the new guide? https://github.com/tock/libtock-c/blob/43525b8fedff3531685dbb20b08916addcca0997/doc/guide.md Maybe not the syscalls folder but the naming convention?