Hi, Thanks for the explanation. I did notice the reason why the macro exists. If the macro was removed an option I thought of was to implement a lazy init for the semaphore into e.g. sem_wait(), sem_post() etc. That path will not work, because like you said, the semaphores exist in many structures as members (pthread_mutex is one good example) both inside the kernel as well as in userspace.
I'm not familiar enough with the OS semantics, this has been a multi-week long learning journey into the NuttX implementation of semaphores, how they work and where/how they are used. I will not be the one to remove this legacy, as the risk is too great. I'll figure out something else for my specific problem, with a smaller chance for regression to working targets. Br, Ville Juven On Wed, Apr 26, 2023 at 6:23 PM Gregory Nutt <spudan...@gmail.com> wrote: > On 4/26/2023 4:10 AM, Ville JUven wrote: > > I know it might be too late to fix the usage of SEM_INITIALIZER macro > > from user space, as many out-of-tree targets might depend on this as > > well, but I'd still like to open a discussion about the possibility of > > removing it from user space. > > > > Why remove it? SEM_INITIALIZER is a non-standard way of initializing > > the semaphore structure. This is only possible because the full > > composition of sem_t is visible to the user, including all of the > > kernel private data (waitlist, priority inheritance info). If the > > composition is hidden / moved (IMO the user should _not_ know the > > implementation defined composition of sem_t) , then the initializer > > list will become unfeasible. > > SEM_INITIALIZER was added many years ago when NuttX was a tiny OS that > was just /mostly POSIX/. Now the OS has grown and matured and stricter > POSIX-like behavior is more mission critical. So I would be supportive > of removing it because it is a tiny step toward POSIX compliance. > > However, you will probably have to deal with the reason why > SEM_INITIALIZER was created in the first place: There are many places > where semaphores are declared and sem_init() cannot be called to > initialize them. For example, when the sem_t is defined but there is no > initialization function that runs to call sem_init() or when the sem_t > is member of a more complex type like an array of structures with unions. > > I am not sure if there are any cases like this in user-space, but if so > those cases will require some re-design. >
