gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] Top issues in the 3.12 cycle


From: Eric S. Raymond
Subject: [gpsd-dev] Top issues in the 3.12 cycle
Date: Thu, 28 Aug 2014 08:00:44 -0400 (EDT)

The days since I shipped 3.11 have been tremendously productive.  I've
heard the usual complaints about the release being too rushed - but
I've also noticed that, as usual, a lot of our regulars and
semi-regulars only seen to go active under that deadline pressure.

With the Debian feeze deadline made we can go back to a more normal
schedule.

Here are the top issues that remain now that the dust has settled a
bit:

1. There are still unresolved porting issues on mips and powerpc
that are breaking interpretation of Type 6 AIS messages.

Bernd Zeimetz: to fix these, I need my expired account of the Debian
porterboxes revived.  When I can actually get to a test environment 
where I can reproduce this bug, I don't expect it to be difficult to
characterize and fix.

As a related point, I'd like to see a full set of test results with
slow=yes.  I'm hoping this will banish flaky failures due to pty
race conditions and allow us to focus on the few real port bugs.

2. Gary Miller and Greg Troxel have an argument going over the
right kind of time capture to do in the PPS code, and another one
about TIOCMIWAIT.  These need to be resolved.

In a related issue, I still don't understand what the negative offset
from the GR-601W means (Gary talks of bugs in the USB driver, and
while I don't doubt him this does not illuminate much).  I want to
document the meaning of negative offsets and the assumptions required
to interpret the offset in general, but that can wait until the code
is cleaned up to their mutual satisfaction.

I am, frankly, not very happy with the ppsthread.c code.  It is
complex and obscure. It has too many magic numbers and undocumented or
semi-documented assumptions. It's top on on my list of Places Bugs 
Most Likely Lurk.  I did what I could by factoring the hell out
of the old code (it was far worse when ntpshm.c and ppsthread.c were
one big lump) but I have reached the limits of what I can do with
the domain knowledge I have.

While you guys are working on this, more attention to making the
code comprehensible would be a good thing.  A nice big 
narrative comment somewhere describing our assumptions about
how PPS is related to the GPS reporting cycle would be a good start.

This is actually also related to one of Hal Murray's issues, which is
better PPS offset display in gpsmon.  I'm blocked on that because
I'm not entirely sure what we should be computing as a "PPS offset".
This needs ti be prominently documented...

3.  State of the Android port.  I've eliminated the reverse linkage
that was blocking that - there is no longer any need for GPSD tools
to define gpsd_report() and gpsd_write() at runtime.

I didn't take the simple callback patch to fix that because I don't
like globals.  The way I did it, the libgpsd code remains fully
re-entrant and thread-safe.

For next release, I'd like Android to be supported out of the box.
It is, after all, probably 99.99% of our deployments by volume.

4. SiRF IV devices are flaky talking to gpsd.

This is a pain in the ass because SiRF owns so much of the consumer
GPS market.  We know part of *why* they're flaky - the IV actually has as
a hard requirement that you wait for command acknowledge before
shipping another commnd string.  The SiRF driver needs to be reworked
to cope.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety."
        -- Benjamin Franklin, Historical Review of Pennsylvania, 1759.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]