no_std support in environments that also avoid alloc

[amboar]

Hello,

I have a patch series that reworks deku for use in no_std environments that also avoid alloc. The most recent revision of the patch series at the time of writing is here:

CodeConstruct/deku@740916f...cc/deku-v0.19.1/no-alloc-4

Two recent PRs by @RatCornu (#578 and #579) touch on issues in similar areas, so I feel there might be some collective interest in what I've put together.

As some background, we (@jk-ozlabs, @mkj and myself at Code Construct) have begun using deku to implement various parts of the DMTF MCTP stack, where we maintain the mctp-rs workspace as well as the Linux AF_MCTP implementation and userspace utilities. Concretely, we've switched to using deku for a device-side implementation of the NVMe-MI specification, which integrates into mctp-dev for userspace emulation and usbnvme for drive management emulation in the form of firmware for an STM32 Nucleo board.

I'm interested in whether the no-alloc effort is something the project would like to integrate?

I recognise the current implementation is quite invasive in that it applies #[cfg(...)] liberally as a means to solve problems. Possibly we could refine the arrangement of the code-base along the lines of no-alloc vs no-std vs std (vs bits?) regions to reduce the noise and make maintenance less of a maze. I'm happy to put in the effort to rework the series into something that is acceptable, or to maintain it out-of-tree until we reach a point where we can consider integrating it.

Cheers,

Andrew

[sharksforarms]

I'm interested in whether the no-alloc effort is something the project would like to integrate

thanks for working on this - this is indeed something we'd be open to integrating!

[amboar]

thanks for working on this - this is indeed something we'd be open to integrating!

Great! I've created a PR for something to comment on:

#582