Esp wifi/more dynamic allocations

[bjoernQ]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request. To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• [ ] I have updated existing examples or added new ones (if applicable).
• [x] I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• [x] My changes were added to the CHANGELOG.md in the proper section.
• [x] I have added necessary changes to user code to the Migration Guide.
• [x] My changes are in accordance to the esp-rs API guidelines

Extra:

• [x] I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

Prefer dynamic allocations over static allocations internally.

Testing

All examples still work

[bjoernQ]

This is certainly better than before, but I'm hoping we can get rid of the huge amount of mallocs eventually.

my thinking was that at least for the things indirectly allocated from the driver via malloc we currently allocate from internal-ram - we don't have control over that with the global allocator

t.b.h. I'm not sure if that would cause problems or not but if it's causing problems those things might be hard to debug

For things only allocated by our code I was fine using the global allocator (since I think these shouldn't cause problems)

[bugadani]

my thinking was that at least for the things indirectly allocated from the driver via malloc we currently allocate from internal-ram - we don't have control over that with the global allocator

This would be a perfect use-case for allocator-api2, that way we could define an InternalAllocator and use that instead of mallocing.

[ProfFan]

my thinking was that at least for the things indirectly allocated from the driver via malloc we currently allocate from internal-ram - we don't have control over that with the global allocator

This would be a perfect use-case for allocator-api2, that way we could define an InternalAllocator and use that instead of mallocing.

I agree, I also saw some (de)allocations happening here within critical-sections, theoretically these should ideally happen through a bounded-time allocator instead of the global allocator (if the global allocator is not bounded time). Have you considered also using a lock-free queue instead?

[bjoernQ]

I'm not sure if I should change Vec into VecDequeue for the queues (i.e. FIFO vs LIFO)

[bjoernQ]

Back to draft after observing this: https://github.com/esp-rs/esp-hal/issues/2274#issuecomment-2446807173

[bjoernQ]

False alarm caused by unintendedly enabling ps-max-modem