Re: [gpsd-dev] [Greg Troxel] [PATCH] Add NetBSD support for RFC2783 PPS.

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> I think I'm getting sender-filtered, so I'm forwarding this for comment.
> 
> This patch is not baked enough yet and should not be applied.

Urgh. Is this the same patch you just sent *without* that
qualification?  Because that one looked safe enough to merge even in
our semi-frozen state (no logic changes to working code) and I did.
It live-tests good under Linux.

> I can split it up into hunks; some of it is ready.
> 
> The situation is:
> 
>   * comments are written in terms of Linux rather than standards (not a
>     big deal, but fixed)

Excellent.  I want that part in now even if we back out the rest.
 
>   * Code to associate a serial port with a /dev/ppsN and find it is
>     actually Linux-specific, rather than RFC2783 (which leaves this
>     unspecified), but it was not ifdefed as such.  For other than linux,
>     I just set the pps fd to the serial fd (POLA, and right on *BSD).
> 
>   * The fetch timeout timespec is inexplicable.  NetBSD appears not to
>     support PPS_CANWAIT, which is surprising, but if one just calls it
>     every second, one gets adequate data (as seen in my debug logs).
> 
>   * The code did not handle getting assert without clear, and decided to
>     use assert (when for my unit clear is correct).

This is clearly not fully baked yet, but since it's not going to break
any capability that's working I'm relaxed about merging it.
 
>   * I casted pps_seq_t to unsigned long as a common printable variable.

That's OK.  

> And what remains is:
> 
>   * There seems to be an assumption that TIOCMIWAIT is always available,
>     which is incorrect.

Eh?  Most of the code is not conditioned on that symbol, so I don't
get what you mean here.

>   * There is no support for (RFC2783-compliant) behavior when
>     time_pps_fetch will not block, and always returns the previous
>     timestamps immediately.  It seems that usleep() is in order, and
>     skipping processing if we don't have a new edge.

No comment; you'll have to implement that and see.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>