Re: [gpsd-dev] [gpsd-commit-watch] [SCM] GPSD branch, master, updated. release-3.10-68-gb7c28ae

[Greg Troxel]

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

> commit b7c28ae9ad786d40fc3a75efd7fa4918670964ae
> Author: Gary E. Miller <address@hidden>
> Date:   Tue Nov 26 15:44:02 2013 -0800
>
>     Fix inane comment in ppsthread.c

inane borders on ad hominem.

My characterization of the comment as nonsensical stands.  The code read

            /* on a quad core 2.4GHz Xeon this removes about 20uS of
             * latency, and about +/-5uS of jitter over the other method */
            memset( (void *)&kernelpps_tv, 0, sizeof(kernelpps_tv));

and because this is just prior to a call to time_pps_fetch, this still
does not make sense.  The timestamp has already been captured in the
kernel, and a few us of latency in fetching the already-captured
timestamp is of no consequence.  So the comment does not make sense, and
does not explain what's really going on.

It does make sense that the fact that time_pps_fetch doesn't wait on
Linux (either - perhaps PPS_CANWAIT is not implemented anywhere) is ok
because the edge was waited for with TIOCMIWAIT.

It is good that you clarified that the code wrongly assumes TIOCMIWAIT
is always defined.   Rototilling to fix that will have to wait until
post 3.11, because It's clearly going to be too disruptive.


I'm surprised that waiting until both sequence numbers are non-zero
caused problems (rather than just skipping the first edge).  I don't see
how the code that figures out which edge is desired when one of the
timestamps is missing.  But that's perhaps an artifact of a vast amount
of code that logically should be ifdef TIOCMIWAIT and isn't.

pgp660Omf89pr.pgp
Description: PGP signature