SHM

[Hal Murray]

> I don't think it can be made bakward-compatible with the existing one,
> though. Which means we might as well write a new triver onforming to the
> POSIX shared-memory interface. 

I'd be happy to make a new driver and use POSIX.  We could call it SHM2, or 
SHMP, or ...

The real question is should we be using shared memory?  There is no way to 
get a wakeup so SHM(posix or not, read-only or not) can't cooperate with your 
EVENTs cleanup.

Should we be thinking of pipes?  My vote would be to send binary rather than 
json.  I think we need a strategy for rolling updates.  Is there any good 
white paper on how to do this?
  Plan A, negotiate the version to use at startup.  That may require a 
bidirectional port.
  Plan B, a clump of names, one for each supported version.
  Plan C, make new additions backward compatible and send current version, 
oldest compatible version, and length.

Or maybe a json designed for ntpd rather than gpsd.


-- 
These are my opinions.  I hate spam.