Discussion:
sysctl for named posix semaphores
Drake Talley
2017-04-29 15:40:18 UTC
Permalink
I'm interested in being able to display information about all active named POSIX
semaphores. I have not been able to find a sane way to do this, and
unless there's something obvious I've missed, it may be worth
considering building a sysctl or some other interface for accessing this
information. A while back in the mailing list there seems to have been
some discussion about building out a "semfs" or some other file system
interface akin to /dev/shm in Linux, but there were concerns about the
POSIX compatibility of that approach.

On a related note in /src/sys/kern/uipc_shm.c there is the following
TODO:

* (1) Need to export data to a userland tool via a sysctl. Should ipcs(1)
* and ipcrm(1) be expanded or should new tools to manage both POSIX
* kernel semaphores and POSIX shared memory be written?


So, it's been acknowledged that a sysctl or some new utility is on the
table, and exporting this data to userland isn't blasphemous, although
perhaps not the most pressing need at the moment. Setting Sys V IPC on
the side, has there been discussion or consideration of similar tools
for POSIX semaphores?



Whether or not it's deemed worth doing, I'd appreciate any info or
references to discussions about this topic since I'm like
to tinker with it on my own if nothing else.


Drake
Konstantin Belousov
2017-04-30 09:16:38 UTC
Permalink
Post by Drake Talley
I'm interested in being able to display information about all active named POSIX
semaphores. I have not been able to find a sane way to do this, and
unless there's something obvious I've missed,
There is no way to do this ...
Post by Drake Talley
it may be worth
considering building a sysctl or some other interface for accessing this
information. A while back in the mailing list there seems to have been
... be it sysctl or any other word.
Post by Drake Talley
some discussion about building out a "semfs" or some other file system
interface akin to /dev/shm in Linux, but there were concerns about the
POSIX compatibility of that approach.
On a related note in /src/sys/kern/uipc_shm.c there is the following
* (1) Need to export data to a userland tool via a sysctl. Should ipcs(1)
* and ipcrm(1) be expanded or should new tools to manage both POSIX
* kernel semaphores and POSIX shared memory be written?
So, it's been acknowledged that a sysctl or some new utility is on the
table, and exporting this data to userland isn't blasphemous, although
perhaps not the most pressing need at the moment. Setting Sys V IPC on
the side, has there been discussion or consideration of similar tools
for POSIX semaphores?
No, such discussion does not make sense, see below.
Post by Drake Talley
Whether or not it's deemed worth doing, I'd appreciate any info or
references to discussions about this topic since I'm like
to tinker with it on my own if nothing else.
The current POSIX semaphores implementation is mostly userspace, see
the lib/libc/gen/sem_new.c source file for details. From the birds view,
a POSIX semaphore is constructed from the shared mapping of a file in
/tmp (presumably tmpfs-backed), and some umtx(2) features to assist in
implementing the acquisition and release operations. Kernel does not
provide complete abstracted object for semaphores.

In other words, there is no way for kernel to enumerate userspace
entities which semaphores are.

The implementation in sys/kern/uipc_sem.c AKA sem.ko is obsoleted ('legacy')
and is provided for ABI compatibility with <= 8.x libc.
Drake Talley
2017-04-30 01:41:00 UTC
Permalink
Ah thanks for cleaing that up; sorry for coming at it from left field.
Really appreciate the explanation though!
Konstantin Belousov
2017-04-30 09:56:10 UTC
Permalink
Post by Drake Talley
Ah thanks for cleaing that up; sorry for coming at it from left field.
Really appreciate the explanation though!
Note that the fact that kernel does not support 'POSIX semaphores'
objects, does not make impossible to get some information about existing
named semaphores for the debugging purposes.

Eg. low-tech method 'ls -l /dev/SEMD*' would list files backing the
named semaphores and show the ownership information. fstat(1) -m
or procstat(8) -v show the processes which currently have specific
semaphore open (AKA mapped). Current state of the semaphore can be
inspected with any file dump tool, even with hexdump(1).

Anonymous semaphores are somewhat harder to observe.

Loading...