A potpurri of memory map-related enhancements:
- Change "number of blocks used" API to "number of blocks free" API, since the latter is more useful. (Or else support both?)
- Allow users to specify alignment of memory map blocks. (Requires an extra argument during initialization.)
- Need to decide how to handle cases where alignment would cause a gap between blocks. (Do we allow this or force the user to ensure that block size is a multiple of alignment?)
- Note that minimum permitted alignment is word-aligned, since kernel uses first word of each block as a pointer when the block is part of the free list.
- Revise memory map APIs to use k_mem_block type, just like memory pools do.
- makes it possible for mailbox to handle blocks from either a memory pool or a memory map
- improves consistency of use for application designers (can more easily switch code from map to pool)
- mailbox can distinguish between block types because memory map blocks will specify a size of 0, rather than the actual block size (as with memory pools)
- might have a legacy issue in that applications are passing in a 1 field structure, rather than a 4 field structure – not sure if we can easily work around this ... (maybe take the approach that the new APIs use the new structure, but mailboxes can't support memory map blocks until the legacy APIs are removed?)