On Tue, Jun 8, 2021, at 5:09 AM Hal Murray <halmur...@sonic.net> wrote: > > > devel@ntpsec.org said: > > IIRC gpsd has a read-only monitor program. I'm not sure how much of the code > > could be applied to revise ntpd/refclock_shm.c, but I think that quite a bit > > of it could. Which with it hopefully being read-only addresses a couple of > > bullet points. I also seem to remember that some PTP software can export via > > the same SHM struct which would drag in a third. > > gpsmon uses a TCP connection to gpsd. There is no shared memory involved.
cgps will use shared memory if "shared memory" is passed on the command line. gpsmon is a bit like ntpd/ntp_signd.c ignored except for getting backhanded every time warnings pop up. > What sort of monitor do you have in mind? > With only a little hacking, we could make NMEA sentences available. Probably something a lot like a clone of ntpshmmon (from the gpsd tree), which does read that shared memory mapping NTPsec uses. JSON is not the subject of those bullet points. > > I had a foolish notion for a revised SHM driver but it just dropped off the > > list. > > There is a way for the client/reader to be read only. Fixing this has been on > my list for years. > > The idea is to use two counters. Call them X and Y. The writer does: > Bump X > update data > Y = X > The reader does > grab Y > grab data > grab X > if grabbed X and Y are equal, data is valid. > The key is that the reader references X and Y in the opposite order from how > the writer updates them. If the reader and writer are accessing the data at > the same time, the reader gets the old Y and new X. I was thinking something more JSON-like parseable, with unlimited extensibility and distinct edges. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
