Hi,
I'm in the process of trying to fix this issue:
https://github.com/apache/nuttx/issues/8917
TL;DR semaphores are unusable when MMU is in use, because the kernel
private data of struct sem_s exists in user space and is not always
visible to the kernel when it needs it. So I'm trying to separate / move
the kernel private data to kernel space (for CONFIG_BUILD_KERNEL only btw.).
I have a question about using mutex_t / struct mutex_s inside libs/libc.
The mutex_t definition is kernel internal but some modules inside the
libs folder use it directly. My question is, is this intentional ? I
don't think such modules should be using mutex_t.
Why not ? libc is userspace code (even though we use it inside the
kernel as well as I guess nothing prohibits this)
What is the problem ? Using NXMUTEX_INITIALIZER uses the kernel private
NXSEM_INITIALIZER macro. I'm trying to separate kernel private data from
semaphores like stated above but there are some corner cases where this
becomes impossible, mutex_t is one example.
The locations where mutex_t is used (there might be others, using
nxrmutex for example):
./libs/libnx/nxmu/nx_connect.c:55:static mutex_t g_nxliblock =
NXMUTEX_INITIALIZER;
./libs/libnx/nxfonts/nxfonts_cache.c:79:static mutex_t g_cachelock =
NXMUTEX_INITIALIZER;
./libs/libc/locale/lib_gettext.c:87:static mutex_t g_lock =
NXMUTEX_INITIALIZER;
./libs/libc/wqueue/work_usrthread.c:65: NXMUTEX_INITIALIZER,
./libs/libc/userfs/lib_userfs.c:73:static mutex_t g_userfs_lock =
NXMUTEX_INITIALIZER;
./libs/libc/stdlib/lib_mktemp.c:68:static mutex_t g_b62lock =
NXMUTEX_INITIALIZER;
My question ? Should these be sem_t or perhaps pthread_mutex_t ? Both of
which are valid user APIs.
Anyone have any idea / suggestions on how to fix this ?
Br,
Ville Juven / pussuw
