> 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
