site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Use standard APIs instead: ? Hope this was the information you needed. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Apr 2, 2008, at 3:33 AM, Christof Rath <c.rath@student.tugraz.at> 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: <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. This email sent to site_archiver@lists.apple.com