Yo Kent!

On Sat, 17 Apr 2021 23:05:11 -0400
Kent Dorfman <kent.dorfman...@gmail.com> wrote:

> I put a guy to work on making our GPIO/UDP TATT function available to
> our embedded linux boxes the other day as an authoritative source for
> ntpd.  My assumption was that I could write a source program that
> received TATT messages over UDP, then forward the TATT message to a
> kernel driver (he's writing) via ioctl() and that kernel driver would
> simply unblock the reading of a /dev/pps device file when the GPIO
> signal is asserted.  The tatt message is sent ~0.5 sec before the GPIO
> and the value of TATT is what the time will be upon assertion.

Why?  Just let the PPS happen from the kernel, and validate that it is
expected in the userland client.

> I had hoped that it would be trivial to configure ntpd to do a
> blocking read of /dev/pps and when it unblocks the value read from the
> node would be the authoritative time.

Just use the standard KPPS calls as they are intended to be used.

> He tells me that from what he can find, a shared memory interface
> between the source and ntpd is simpler to implement.

Apples and Oranges.  For example, gpsd, reads /dev/pps0, validates
that the PPS is valid, then stuffs the time data in the shared memory
slot.

> What we are
> unclear of at present is who "owns" the shared memory segment.

"ipcs" tells you that.  "root" owns them.  The first two are permissions
600, the rest are 666

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x4e545030 0          root       600        96         2                       
0x4e545031 1          root       600        96         2                       
0x4e545032 2          root       666        96         3                       
0x4e545033 3          root       666        96         1                       
0x4e545034 4          root       666        96         1                       
0x4e545035 5          root       666        96         1                       
0x4e545036 6          root       666        96         1                       
0x4e545037 7          root       666        96         1                       



> I
> would speculate that the sender should create and own the segment as
> the "server" of the data, and that ntpd creating and owning the
> segment it reads timestamp data from would be an anti-pattern.

No process "owns" the SHM.  Think of it just like a file.

> Can someone elaborate on which is implemented, and why?

I suggest that you just read the source.  Look in gpsd as the sender
and ntpd as the receiver.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        g...@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpDGRyfFsRzS.pgp
Description: OpenPGP digital signature

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to