<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 5, 2016 at 9:24 PM, Norton Allen <span dir="ltr"><<a href="mailto:allen@huarp.harvard.edu" target="_blank">allen@huarp.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5/5/2016 5:17 PM, Gary E. Miller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 5 May 2016 16:48:26 -0400<br>
Frank Nicholas<<a href="mailto:frank@nicholasfamilycentral.com" target="_blank">frank@nicholasfamilycentral.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> >communicates with ntpd via SHM. It's not clear why refclock 20<br>
> >should survive thaat transition when gpsd is already better at<br>
> >adapting to weird sentence inventories than it is.<br>
</blockquote>
><br>
>How portable is “SHM”? <b><snip></b><br>
</blockquote></blockquote><br></span>
I know SHM is not portable to QNX, which has shm_open() POSIX 1003.1. I am still hoping to work on getting gpsd+PPS-SHM working, but have been sidetracked by other work. But that leaves me with refclock #46, and it sounds from the discussion here as though that is essentially deprecated. And yes, my intent is to get both time and position, which is why gpsd is in the mix.</blockquote><div><br></div><div><br></div><div>RefClock 46 is NOT deprecated. This is actually a preferred solution as it should be more portable than SHM. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rather than bump up to shm_open(), I'd like to add sockets. Chronyd<br>
uses sockets as an optional alternative to SHM. This is more flexible,<br>
more secure, and allows the consumer to wait for data instead of<br>
polling. Any process that can write to SHM can smash the clock. It<br>
does make things like ntpshmmon impossible.<br>
</blockquote></span>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sockets sounds like a good option.<br><br>
</blockquote></div>Agreed</div><div class="gmail_extra"><br></div><div class="gmail_extra">Clark B. Wierda</div><div class="gmail_extra"><br></div></div>