Feature: Support embedded async runtime

[taqtiqa-mark]

This is post issue #113 landing.

Embedded device use cases will likely have trace requirements that Minitrace could support.

One of several steps for this to be realized is to support the embedded async runtime Embassy.

Potentially significant changes to the integration test harness/setup may be required.
Hence, I'm flagging this as something to add only once the macro refactor in #113 has landed.

• Identify PoC test case: minitrace-tests/src/build/defaults/no-be-no-drop-local.rs. this test case is already broken in the existing implementation, issue Bug: Missing BE silently compile and run. #126. Hence breaking it further by having it be the PoC doesn't add additional noise.
• Add Qemu to test environment
• Add async runtime Embassy to [features] for integration tests (minitest-tests crate): This has landed as part of RFC proc-macro structure #113 via PR Proc-macro pipeline (issue #113) #127. This was done to ensure we didn't set up the test configuration in a way that makes adding embassy more difficult than it needs to be.
• Alter main in integration tests, i.e. now have three cases for execution of async functions.
• Introduce test pro-macro #[trace_test(...)] or trace_test!(...) to setup testing boiler plate code.

References:

• https://github.com/embassy-rs/embassy

[andylokandy]

I'm curious how minintrace could be used in an embedded environment which usually doesn't support allocation, not to mention the threading. Besides, since much effort on minitrace has been taken to address thread synchronization and eliminate allocation, minitrace may not be the most optimal in a fully statical environment.

[taqtiqa-mark]

I'm curious how minintrace could be used in an embedded environment which usually doesn't support allocation, not to mention the threading. Besides, since much effort on minitrace has been taken to address thread synchronization and eliminate allocation, minitrace may not be the most optimal in a fully statical environment.

Agree this is in the realm of experimental, and MT would have to support no_std in some fashion.
I believe, unless my understanding is wrong, that, via the exercise of supporting embedded constraints, MT performance could be enhanced - speculation.
Ack not all of MT functionality would be of interest in those contexts.

Anyway, I'm trying to set up the integration test harness in such a way that it, the test harness, is not a blocker in case anyone wants to drive this forward.

I suppose you just need to decide, and document, if you rule it as out-of-scope for MT?

[taqtiqa-mark]

Voided by PR #127 rejection.