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

[Norton Allen]

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”?
> Mostly portable, it is SYSV-r4, and POSIX-2001.
>
> Windows is different, but simple shims are possible.
>
> Some people deprecate shmctl() and recommend the newer shm_open().
>
> shm_open() is also POSIX-2001 and has UNIX everything is a file semantics.
>
> > >Is it covered everywhere NTPSec wants to go?
> Windows....
>
> > >Is GPSd portable to everywhere NTPSec wants to go? (I’m asking, not
> > >arguing - I don’t know the answers).
> Windows...

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.
> 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.