gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Clark B. Wierda
Subject: Re: [gpsd-dev] New 0.5 draft of the SemPiTernal HOWTO
Date: Thu, 5 May 2016 21:31:47 -0400

On Thu, May 5, 2016 at 9:24 PM, Norton Allen <address@hidden> wrote:
On 5/5/2016 5:17 PM, Gary E. Miller wrote:
On Thu, 5 May 2016 16:48:26 -0400
Frank Nicholas<address@hidden>  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]