<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 26, 2019 at 7:49 AM Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">James Browning via devel <<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>>:<br>
> I would like to propose a new SHM implementation<br>
<br>
The trouble with any new SHM proposal is that the underlayer is not<br>
POSIX and we theefore can't count on it continuing to exist.<br>
<br>
We need that kind of funcrionality, but any new design should be dome<br>
over an IPC layer that's POSIX/SuSv2.</blockquote><div> </div><div>I do not have access to a copy of POSIX and the SuSv2 seems to have<br>SHM support. Changing it to use say a UNIX socket would allow for<br>simpler packet design. Up to six bits for the version another two for<br>leap second status and then an octet for precision. Then the body<br>which could be a pair of timestamps. Then possibly refclock and<br>hostname overriding text fields.<br></div></div></div>