Hello,
While back I started to look how to get util-linux ipcs(1) tool to
read values from /proc instead of using IPC multiplex functions. Most
of the data ipcs(1) is interested is available in /proc, but there are
few exceptions, such as
msgctl q_qbytes
semctl getval
semctl sempid
semctl semncnt
semctl semzcnt
The simplest thing to do would be to add values in /proc/sysvipc/msg
and /proc/sysvipc/sem as additional fields, but that does not seem
right, as it would result to ABI change.
More effort requiring change would be to add information in new sysfs
paths. The IPC facilities are using id's which could be used as
placeholder directories for the data needed. Something like
/proc/sys/kernel/ipc/{m,s,q}/id/info
^^^^^^^^^^^^^^^^^^^
That sort of structure would allow future extensions IPC data without
much pain. I also assume that subdirectories could allow a little
more precise controls, and perhaps some selected values might be made
writable in future. If nothing else at least expressing in sensible
format semaphore lock wait queues could make debugging tools, such as
lslocks(8), more useful.
I could give a try this change, but not without hearing the concept
makes sense and could be considered part of upstream kernel (assuming
my coding meets the usual quality criteria).
Any thoughts, comments, recommendations?
--
Sami Kerola
http://www.iki.fi/kerolasa/
On Sun, 18 Nov 2012 12:31:08 +0000
Sami Kerola <[email protected]> wrote:
> Hello,
>
> While back I started to look how to get util-linux ipcs(1) tool to
> read values from /proc instead of using IPC multiplex functions. Most
> of the data ipcs(1) is interested is available in /proc, but there are
> few exceptions, such as
>
> msgctl q_qbytes
> semctl getval
> semctl sempid
> semctl semncnt
> semctl semzcnt
>
> The simplest thing to do would be to add values in /proc/sysvipc/msg
> and /proc/sysvipc/sem as additional fields, but that does not seem
> right, as it would result to ABI change.
>
> More effort requiring change would be to add information in new sysfs
> paths. The IPC facilities are using id's which could be used as
> placeholder directories for the data needed. Something like
>
> /proc/sys/kernel/ipc/{m,s,q}/id/info
> ^^^^^^^^^^^^^^^^^^^
>
> That sort of structure would allow future extensions IPC data without
> much pain. I also assume that subdirectories could allow a little
> more precise controls, and perhaps some selected values might be made
> writable in future. If nothing else at least expressing in sensible
> format semaphore lock wait queues could make debugging tools, such as
> lslocks(8), more useful.
>
> I could give a try this change, but not without hearing the concept
> makes sense and could be considered part of upstream kernel (assuming
> my coding meets the usual quality criteria).
>
> Any thoughts, comments, recommendations?
Where's the benefit in switching ipcs over to using /proc?
procfs reads are probably slower than the syscalls?
On Mon, Nov 19, 2012 at 04:12:50PM -0800, Andrew Morton wrote:
> Where's the benefit in switching ipcs over to using /proc?
>
> procfs reads are probably slower than the syscalls?
32bit userspace and 64bit kernel (RHEL ppc64), it seems more reliable
read from /proc than use the syscalls.
I guess that IPC_64 flag for shmctl() commands is used by libc in 64bit
userspace only.
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
On Tue, Nov 20, 2012 at 12:21 PM, Karel Zak <[email protected]> wrote:
> On Mon, Nov 19, 2012 at 04:12:50PM -0800, Andrew Morton wrote:
>> Where's the benefit in switching ipcs over to using /proc?
>>
>> procfs reads are probably slower than the syscalls?
>
> 32bit userspace and 64bit kernel (RHEL ppc64), it seems more reliable
> read from /proc than use the syscalls.
>
> I guess that IPC_64 flag for shmctl() commands is used by libc in 64bit
> userspace only.
It seems there is not much interest to have more IPC information
available in user space. Fair enough, and since nothign is exactly
broken so we can live with this.