Old vs. new shared-memory primtives

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> ntpd, chronyd and gpsd use shmctl(2), the old SYSVr4 interface.
> 
> The 'new' as of 2001 interface is shm_open(3).
> 
> Both are in POSIX 2001 and POSIX 2008.
> 
> man shm_overview has this to say:
> 
>        "System  V  shared  memory (shmget(2), shmop(2), etc.) is an older
>        shared memory API.  POSIX shared memory provides a  simpler,  and
>        better  designed interface; on the other hand POSIX shared memory
>        is somewhat less widely available (especially on  older  systems)
>        than System V shared memory."
> 
> In any case, they are not trivially interchangeable at the binary level.
> So a refclock based on shm_open() would be a new refclock.  IMHO it would
> be slightly better than shmctl(), but I'd prefer to go all the way and fix
> #48, skipping these intermediate steps.

I did not know this.  Topic for investigation: can we write code using
the new interface that interoperates cleanly with the old one?

Looking at shm_overview it looks like this should be almost possible.
If I'm reading the tea leaves correctly, shm_open(2) returns a
shared-memory area with the access semantics of a file.  The base
address of the segment is unavailable, and memcpy() operations have to
be replaced with read()/write(), but these are details.

The problem is we don't know what, if any, mapping is possible between
shmget segment keys and shopen filenames.  Grr.  There may not be one.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160528/a7f4611e/attachment.bin>