b10428163a
Currently there is no way to distinguish between a caller explicitly asking for a semaphore with a limit that happens to be `UINT_MAX` and a semaphore that just has a limit "as large as possible". Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin to `K_FOREVER` versus just passing some very large wait time. In addition, the `k_sem_*` APIs were type-confused, where the internal data structure was `uint32_t`, but the APIs took and returned `unsigned int`. This changes the underlying data structure to also use `unsigned int`, as changing the APIs would be a (potentially) breaking change. These changes are backwards-compatible, but it is strongly suggested to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with `UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT` where appropriate. Signed-off-by: James Harris <james.harris@intel.com> |
||
|---|---|---|
| .. | ||
| arm_interrupt | ||
| arm_irq_advanced_features | ||
| arm_irq_vector_table | ||
| arm_no_multithreading | ||
| arm_ramfunc | ||
| arm_runtime_nmi | ||
| arm_sw_vector_relay | ||
| arm_thread_swap | ||
| arm_tz_wrap_func | ||