visiting the todo list

[James Browning]

On Tue, Jun 8, 2021, at 5:09 AM Hal Murray <halmurray at sonic.net> wrote:
>
>
> devel at 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.