CMSIS RTOS v2 Portability Layer - Thread Stack Size

[htcrane]

From my embedded systems experience, when I use an RTOS I configure the OS buffer size and can divvy that up however I wish. For example I create 3 threads of various sizes say 1KB, 2 KB, 3KB (6KB of threads in total) and as long as the total is below the OS buffer size all is well. This is also the approach the CMSIS RTOSv2 wrapper takes when creating a thread where the osThreadAttr_t member stack_mem is NULL. The programmer specifes the stack size in bytes via the stack_size member. CMSIS expects the underlying OS to allocate "the memory for the stack is provided by the system based on the configuration of underlying RTOS kernel" per the CMSIS documentation.

However, Zephyr's implementation decides not to follow so nor documents the deviation from this...

Zephyr's implementation decides that dynamic allocation will not follow CMSIS's documentation and instead allocates a stack array of CMSIS_V2_THREAD_DYNAMIC_STACK_SIZE by CMSIS_V2_THREAD_DYNAMIC_MAX_COUNT. Zephyr does not respect the requested thread stack size, rather yielding each thread to be the same size. To our example above, I would have to set the dynamic size in the KConfig to be 3KB, each thread takes 3KB for 9KB in total with a third being wasted space.

Looking through the commit history of the thread.c file for CMSIS RTOS v2, the only hint I can find as to why is a message from 2019. Why not allocate a CMSIS heap to use for thread creation, like other RTOSs, and divvy up based on the requested size instead of silently assigning a static size? For alignment purposes, could just round the programmer provided size up to the nearest valid aligned size when threads are created with dynamic memory. Am I missing something?