[gpsd-dev] New 0.5 draft of the SemPiTernal HOWTO

Clark B. Wierda cbwierda at gmail.com
Fri May 6 01:31:47 UTC 2016


On Thu, May 5, 2016 at 9:24 PM, Norton Allen <allen at 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<frank at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160505/08b74919/attachment.html>


More information about the devel mailing list