On Thu, May 5, 2016 at 9:24 PM, Norton Allen <al...@huarp.harvard.edu> wrote:
> On 5/5/2016 5:17 PM, Gary E. Miller wrote: > >> On Thu, 5 May 2016 16:48:26 -0400 >> Frank Nicholas<fr...@nicholasfamilycentral.com> wrote: >> >> > >communicates with ntpd via SHM. It's not clear why refclock 20 >>>> > >should survive thaat transition when gpsd is already better at >>>> > >adapting to weird sentence inventories than it is. >>>> >>> > >>> >How portable is “SHM”? *<snip>* >>> >> > 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. RefClock 46 is NOT deprecated. This is actually a preferred solution as it should be more portable than SHM. > Rather than bump up to shm_open(), I'd like to add sockets. Chronyd >> uses sockets as an optional alternative to SHM. This is more flexible, >> more secure, and allows the consumer to wait for data instead of >> polling. Any process that can write to SHM can smash the clock. It >> does make things like ntpshmmon impossible. >> > > sockets sounds like a good option. > > Agreed Clark B. Wierda
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
