Hi, Thanks for the explanation, it makes sense. I had an idea to move struct sem_s entirely to kernel and make the user use it via a handle (in KERNEL build) but due to the ubiquitous init macros, that is not a feasible solution.
I will explore allocating the kernel structures on-demand next. What does this mean ? The kernel side structures (dq_waitlist and priority inheritance holders) are only needed when the semaphore is locked and someone is actually waiting for it to be released. This means that when sem_wait() results in the thread getting blocked, the kernel part can be allocated here and a reference placed into the user sem_t structure. When the semaphore unlocks, the kernel parts can be freed. This should be completely regression free for FLAT/PROTECTED, which is very important for me because I don't want to be responsible for breaking such a fundamental OS API for current users ;) Br, Ville On Wed, Apr 26, 2023 at 5:26 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > 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. > > >
