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.

Reply via email to