MCTP stack for no_std, no runtime baremetal use

[embediver]

We a currently in the process of developing a no_std bare-metal mctp-stack, that can be used to implement mctp on different platforms/frameworks.

Currently mctp-estack is geared towards the embassy framework, but at the same time implements a stack, fragmenter and transport bindings in a platform independent way.

We are currently using these by disabling anything embassy specific through feature-gates.

Are you interested in getting these efforts upstreamed, or are willing to discuss other ways to provide these core features independently of a embassy mctp-stack?

[jk-ozlabs]

Hi!

Yes, we'd be interested in making things usable without embassy; we just needed some async executor for the async support, and embassy was what we are currently using for that. I am assuming you're referring to something along the lines of main...9elements:mctp-rs:embassy-feature .

In general, then that sounds reasonable, I'd just suggest doing the gating on a single async feature perhaps?

(assuming hurbis, you're not using async at all for your stack, right?)

[mkj]

Just to clarify what @jk-ozlabs said (more for anyone else reading vs this no-async case), mctp-estack isn't using Embassy executor, only embassy-sync for CriticalSectionRawMutex and some internal data structures. So Router will work fine with other async executors. We use it with smol executor too.

[embediver]

Thanks for the feedback!

assuming hurbis, you're not using async at all for your stack, right?

Yes, we are currently implementing a router for that purpose: OpenPRoT/mctp-lib#3.
At this point it only adds some functionality to track listeners and request/response handles to support an easy implementation on different platforms.
(Implementing the blocking mctp-rs traits directly didn't seem useful without any runtime, this would probably change if someone needs a nb version)

There are still frequent changes while we work on an implementation for hubris, but that should provide a good basis to evaluate the router/stack.

I'd just suggest doing the gating on a single async feature

Sounds good, I can tidy things up and open a PR. (And maybe already include a non-async version of the serial transport, we worked on.)

Once I have some experience with the hubris implementation, we can discuss in what form a non-async router should be included in the estack, of if it should continue living in its own crate.