Implement a userpsace low-level debug API for Tock 2.0

[kupiakos]

This resolves "Implement a LowLevelDebug driver" in #322.

[jrvanwhy]

Looks good overall, my comments are mostly stylistic nits.

[jrvanwhy]

In general, libtock-rs APIs should not return CommandReturn directly, they should interpret it according to the documentation for the SyscallDriver they are interfacing to. LowLevelDebug is kind of unique in that its documentation says its commands should always return Success. Based on that, I think print_alert_code, print_1, and print_2 should just ignore the value returned from command.

What do you think?

[kupiakos]

In general, libtock-rs APIs should not return CommandReturn directly, they should interpret it according to the documentation for the SyscallDriver they are interfacing to. LowLevelDebug is kind of unique in that its documentation says its commands should always return Success. Based on that, I think print_alert_code, print_1, and print_2 should just ignore the value returned from command.

What do you think?

My gut says no, keep it just in case, my brain says yes, errors should be silenced. I can't think of a realistic scenario where you would do something different if LowLevelDebug operations failed, since it exists for when other options fail.

[jrvanwhy]

I just noticed that the low-level debug API is not exported from libtock2. We should export it, using something like the following (in libtock2/src/lib.rs):

pub mod low_level_debug {
    type LowLevelDebug = libtock_low_level_debug::LowLevelDebug::<runtime::TockSyscalls>;
    pub use libtock_low_level_debug::AlertCode;
}

This will require adding libtock_low_level_debug as a dependency of libtock2.

[kupiakos]

@jrvanwhy Added those exports. I considered having it be gated by a default-enabled feature in libtock2, but considering the low level debug API has no runtime overhead, I think it'll be fine.

[jrvanwhy]

bors r+

[bors]

Build succeeded:

• ci
• size-diff