Usage of SEM_INITIALIZER in apps, userspace in general

[Ville JUven]

Hi,

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.

Inside the /apps folder I see only a handful of references which should 
be fixable by using the standard sem_init() function instead.

I do not have a strong opinion about this, I'm fine with keeping it and 
I can wrap around the issue keeping any existing code functional/intact. 
I just think it is a bit odd and confusing to have such non-standard 
quirks in the otherwise well defined user API.


BR,

Ville Juven / pussuw


To clarify, I am _not_ proposing we remove NXSEM_INITIALIZER, which is 
ubiquitous inside the kernel, and is completely fine to use there.