Proposal - drop the GPSD JSON driver

Hal Murray hmurray at
Wed Oct 19 10:51:29 UTC 2016

I think you should leave it until we get our act together, and I think you 
should put that on the back burner until 1.0 is out.

> For communication with GPSD, the SHM driver seems superior; it certainly has
> lower processing overhead and therefore introduces less noise into the
> delivery chain. 

It has a different type of noise.  There is no "ready" signal on SHM so the 
driver polls and the timing on that is just the luck of when ntpd was started.

I think the SHM driver is pretty ugly.  It got a lot less ugly when you added 
the memory barriers a year or two ago.  I think we should rewrite it to use 
the 2 counters trick so the readers are read-only.  But let's save that 
discussion for another time.
I'm missing the big picture.  The JSON driver was written because I (and 
probably others) thought you thought that JSON was the right way to talk to 
gpsd.  Was that wrong and/or did anything change?

Can POSIX SHM talk to non-POSIX SHM?  I assume the concepts are the same (map 
a chunk of memory where I can see it).  Are there different name spaces?

Would pipes work better?  Or a network connection passing the same (binary) 
info as is in the SHM segment?

These are my opinions.  I hate spam.

More information about the devel mailing list