Johnathan Van Why

Note: I'm going to keep separate opinions in separate comments, so you can thumbs up/down them individually. I think Tock's no-external-dependencies policy is too strict, and we should be somewhat...

If we decide to use external libraries, I would prefer to pull them in via standard cargo mechanisms for two reasons: 1. Vendored dependencies are more effort to maintain than...

> How to format the files correctly? [0de4540](https://github.com/tock/libtock-rs/commit/0de4540801990c020a54e90a23c14ee7b98314e8) is the result of running `cargo fmt` on my side, but the CI is clearly configured with some other formatting rules. Unfortunately,...

Looks to me like we do support the Raspberry Pi Pico: https://github.com/tock/libtock-rs/blob/master/runtime/layouts/raspberrypi_pico.ld

We look at the [target architecture](https://github.com/tock/libtock-rs/blob/1d785a043a95d83b410f6a099a6121fc101ca3b7/.cargo/config#L9) to determine whether we are building for the host or an embedded target... which is incorrect and will fail if your host system is...

These macros belong in `libtock_console`.

I just realized why you originally put these into `libtock` -- they depend on `libtock_runtime::TockSyscalls`. I did not notice that at first. That's a tricky dependency. `libtock_console` should not depend...

> Given that the macros require importing Console, I'm okay with the current placement. If that's the case, then you should make the caller specify the `Syscalls` implementation.

Drivers must not depend on `libtock_runtime`, either directly or indirectly, because such a dependency would prevent us from unit-testing them. Adding a *temporary* dependency on either `std` or `libtock_runtime` while...

Wait, when you say "debugging drivers", do you mean debugging syscall drivers in the Tock kernel, or debugging APIs in the `apis/` directory of `libtock-rs`?