Messages in this thread | | | Date | Mon, 19 Nov 2012 16:12:50 -0800 | From | Andrew Morton <> | Subject | Re: ipc: object information data in proc and sysfs |
| |
On Sun, 18 Nov 2012 12:31:08 +0000 Sami Kerola <kerolasa@iki.fi> 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?
| |