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.
...
My question ? Should these be sem_t or perhaps pthread_mutex_t ? Both
of which are valid user APIs.
It was sem_t before it was changed to the non-standard mutex_t. See
commit d1d46335df6:
commit d1d46335df6cc1bc63f1cd7e7bffe3735b8c275d
Author: anjiahao <anjia...@xiaomi.com>
Date: Tue Sep 6 14:18:45 2022 +0800
Replace nxsem API when used as a lock with nxmutex API
Signed-off-by: anjiahao <anjia...@xiaomi.com>
Signed-off-by: Xiang Xiao <xiaoxi...@xiaomi.com>
Parts of the above which introduce inappropriate use of mutex_t could be
reverted back to sem_t. Any use of any non-standard OS function or
structure should be prohibited in application code.
However, nuttx/libs is a special creature. It is not confined by the
rules of POSIX interface because user-space libraries are a
non-privileged extension of the operating system. They have intimate
knowledge of OS internals and can do non-standard things to accomplish
what they need to do. So although I think it is wrong architecturally
for applications to use OS internals, I don't think it is wrong for
nuttx/libs to do so. It is a friend of the OS.
But it is should not break the KERNEL build either.
Perhaps we will need a user-space function to allocate (and initialize)
kernel memory. Use of such functions should not performed outside of
nuttx/libs, although we have no way to prohibit that use: Such an API
would be a security hole. user-space code cannot access kernel memory,
but it can use the kernel memory address like a "handle" to interact
with the OS.
