021923b58a
Picolibc has both recursive and non-recursive mutex uses. The bulk of the library locking uses the global libc lock, which is a recursive mutex as that greatly simplifies the implementation. The only use of non-recursive mutexes is in the stdio code when dealing with file system I/O via fopen. Using mutexes for both APIs is valid; the assumption picolibc makes is that the non-recursive mutexes are somehow cheaper or faster and should be preferred. However, in Zephyr, recursive mutexes are the default and the non-recursive locks for picolibc were implemented using semaphores. Switch the non-recursive picolibc locks to just invoking the existing recursive functions using mutexes. This avoids pulling in another lock implementation, saving a bit of space. This also lets the kernel.memory_protection.mem_map test work on qemu_x86_tiny where the amount of memory available is 320kB and that is nearly filled by this test case, leaving too little space for allocating pages in the k_mem_map_unmap test. Signed-off-by: Keith Packard <keithp@keithp.com> |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| Kconfig | ||
| libc-hooks.c | ||