Re: SHM_INFO and SHM_STAT
Re: SHM_INFO and SHM_STAT
- Subject: Re: SHM_INFO and SHM_STAT
- From: Terry Lambert <email@hidden>
- Date: Wed, 02 Apr 2008 10:43:34 -0700
On Apr 2, 2008, at 3:33 AM, Christof Rath <email@hidden>
wrote:
Hello Terry (and the rest of you),
I sent your notes to the lead programmer of the framework I try to
compile and got a reply that I would love to forward to you:
Use standard APIs instead:
<http://www.opengroup.org/onlinepubs/009695399/functions/shmctl.html
>
?
SHM_INFO you can emulate by writing code to popen the "ipcs"
command. You are better off using ftok(0 to identify a shared
memory segment key specifically, rather than trying to figure out
the next available one.
It's pretty bad that the ipcs code is not available to use the API
that this program uses directly. What we are trying to do is
enumerate all existing shared memory segment for peeking into them
to see if we find our own shared memory segments.
I suspected as much, which is why I suggested that ftok(), which is
the industry best common practice for establishing a rendezvous for
System V shared memory segments, be used instead. Other methods are to
mmap() a well known file, use shm_open() on a well known (to your
program) name, pass around a handle to a shared vm region using Mach
APIs, etc..
The method we use to iterate shared memory segments for ipcs is sysctl
using a structure containing a cursor field. It's possible to use
this directly, but since the cursor is in a data structure that has to
be modified by user space on the way in, the approach is limited to
the root user, due to the nature of sysctl.
This SPI has changed twice so far, and will likely change again for
architecture support reasons. Because of this, the SPI contract is
between the kernel and the ipcs program in user space, and not with
user applications. To obtain the structure involved, you will need to
obtain xnu sources.
Additionally, access to shared memory segments is restricted by an
ipc_perm structure, per the UNIX standard. Clearly, if you were
running as root, you could ignore this and nose around in all the
segments trying to find yours - but would you trust someone else to so
the same with your segments, containing potentially sensitive data,
and knowing they might make a mistake?
SHM_STAT does not appear to be a useful API, since it only returns
an array index, and that array index could in no way be useful to
you directly, since you can't access the array which is being
indexed by the number which would be returned.
Wrong. It is helpful for the mentioned enumeration. For IPC_STAT you
need a shmem ID, for SHM_STAT you can use the kernel-internal array
index and you can get the length of the array with SHM_INFO and thus
you can iterate really smoothly over all existing shared memory
segments. This code works on FreeBSD as well which makes it
especially cumbersome that Apple left this part of useful code out.
The SHM_STAT exposes internal kernel structures which can and do
change on software updates. It is a design error to expose such
structures for use in third party program, even for Linux or FreeBSD.
Doing so damages either (a) the ability to maintain binary
compatibility with third party software or (b) the lattitude of the OS
vendor to transparently fix bugs.
SHM_LOCK/SHM_UNLOCK are really dangerous, since you are asking that
the memory region be wired down. You can ask for this via the
standard interfaces mlock() and munlock(). Typically, this is a
bad idea. Wiring down physical memory is constrained by
administrative limits which can not be bypassed, so if you ask for
too much, you will get none. These interfaces work equally well in
Linux, and are more portable.
True, but there are situation when you need it in a real-time
robotics domain were you cannot afford if your critical data section
has been swapped away...
There are so many scheduler, ACPI, SMI, power and thermal management,
and other assumptions in this statement, I have no idea how to go
about addressing them...
All I need is the ipcs source or a note on how this program
enumerates all existing shared memory segments.
See above for both this information, and why it undesirable for you to
use it from a code portability perspective, as well as industry best
common practice, which would allow you to avoid the need.
Hope this was the information you needed.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden