Re: [gpsd-dev] Updated docs on NTP segment management

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > Do we really need to use a context-free language for this? I
> > personally would prefer something that can be parsed with couple
> > strcmp/sscanf calls.
> 
> Gack.  gpsd tried the sscanf approach and it is very deli[c]ate.

What Gary said, * 10e6.

/me rubs his burn scars.

Using JSON as a metaprotocol was probably the single *best* design
decision I've made on a project that I believe has had an
above-average share of good ones.

> > I think phk is planning to use a simple text protocol in the new ntpd
> > replacement (ntimed) as the main protocol for all refclocks, which
> > will run in separate processes. If gpsd spoke that, maybe it could be
> > connected directly without having to run a special driver for
> > conversion.
> 
> I suspect gpsd would support any refclock protocol we could figure out.

Bet on that.  We have *lots* of experience with implementing odd
application protocols here. Even very badly designed ones, and I don't
expect phk's to suck.
 
> We (gpsd devs) would certainly like to hear any ideas.  The current
> methods are problematic.

Yes.  I wrote a better implementation of NTP's end of the SHM thing
yesterday and today, starting from what's in nptd/refclock_shm.c.  The
biggest problematic thing I fixed was the lack of memory barriers to
guarantee correctness under concurrent access by multiple writers.  
It's disturbing that this hasn't been done in ntpd itself.

(The reason for this was the new ntpmon tool, now part of the GPSD
suite and documented. My intent is to use it to make interesting 
visualizations of refclock performance.)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>