Re: [gpsd-dev] [PATCH] Time Service HOWTO: Clarify state of RFC2783 on NetBSD.

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

>> huh?  For real serial ports, it's been there about 15 years (and
>> working with ntpd directly).  It's only the odd case of USB-serial
>> PPS that is recent.
>
> Everytime I asked someone to test it I got nothing, I assumed it was
> known broken.

I think I was the first one to actually try to test PPS (at all) with
gpsd.  IIRC it wouldn't even compile.  I created and I think esr merged
a commit that had a partial fix, basically to ifdef linux some
Linux-specific things (use of /sys and /dev/ppsN).  It's

  commit 7d06e770d5f4f8e903a5720a924a93901a140a69
  Author: Greg Troxel <address@hidden>
  Date:   Sun Nov 24 14:18:49 2013 -0500

The key point in the commit, which I had forgotten about because it was
wicked easy to fix, is:

+#ifndef linux
+    /*
+     * On BSDs that support RFC2783, one uses the API calls on serial
+     * port file descriptor.
+     */
+    ret  = session->gpsdata.gps_fd;
+#else /* linux */
+    /*
+     * On Linux, one must make calls to associate a serial port with a
+     * /dev/ppsN device and then grovel in system data to determine
+     * the association.
+     */
  [much much more to figure out the fd]

> RFC2763 specifies no API for determining the control device.  So more than
> unclear, totally unspecified.

I now understand what you mean by unspecified, in that what an
"appropriate special file" is to get a pps_handle is left unclear with
the following text:

   All of the other functions in the PPS API operate on PPS handles
   (type: pps_handle_t).  The time_pps_create() is used to convert an
   already-open UNIX file descriptor, for an appropriate special file,
   into a PPS handle.

   The definition of what special files are appropriate for use with the
   PPS API is outside the scope of this specification, and may vary
   based on both operating system implementation, and local system
   configuration.  One typical case is a serial line, whose DCD pin is
   connected to a source of PPS events.

I read this as leaving unclear which devices did PPS (but implying that
of course one used the special file corresponding to the device since
how else would you do it!), and was quite boggled to learn all about
using /proc to find /dev/ppsN.  But that's not important now, as the
gpsd code is there for both BSD and Linux now, and it was sufficiently
easy and even uncontroversial to fix last year that I had completely
forgotten about it.

The next problem was deeper, where somehow things went in a loop, and
(I'm gradually paging this back in) the support for RFC2783 seemed to
assume that TIOCMWAIT was implemented (which it's not on NetBSD, so
there needs to be something that pauses and gets the timestamps
occasionally, because apparently neither Linux nor BSDs implement
timeouts on fetch).  So what's needed is to write the RFC2783 code just
in terms of RFC2783 calls, without using TIOCMWAIT and without relying
on PPS_CANWAIT).   That's how ntpd uses RFC2783 calls.

>> Because esr added a doc change which was wrong, and that needs to be
>> fixed.
>
> OK, what did he break?

He said PPS support was added to NetBSD in 2014, which is wrong because
it's off by 15 years, and wrong the other way because it doesn't (yet)
work with gpsd.

I sent a new patch with more narrow changes to explain things, and tried
to make it clearer to respond to the points you raised.

pgpMZfFC7huza.pgp
Description: PGP signature