| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to view the "slow" as well as the normal
WRITE_PAD values with gpsfake -T, without having to look at the source
code. It adds a new GetDelay() function to fake.py, which returns the
proper delay value, taking into account both the possible environment
variable and the "slow" option. This is now used for all hree uses of
WRITE_PAD.
Because the environment override is now part of the function, the
WRITE_PAD constant is no longer modified by the environment value, but
instead reflects the platform default.
TESTED:
Ran the full set of regression tests, with both default and acceptably
shortened WRITE_PAD. Also verified that a zero value causes trouble
(OSX), and that adding -S to the zero value makes it work.
Signed-off-by: Jon Schlueter <jon.schlueter@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on timing, in TCP mode, gpsd may try to reconnect to fake.py
between the time that the logfile is complete and the time that the
remove_device is issued. With no listener, this results in a set of
three error messages from gpsd. They don't affect the test outcome,
since they only go to stderr and the "real" output is complete, but
they're annoying to the user.
The likelihood of this happening increases with longer logfiles and
with larger WRITE_PAD values. With a 30ms WRITE_PAD (the default on
OSX), most logfiles exhibit this on all platforms, though it's not
seen on Linux with the default zero WRITE_PAD.
The fix is simply to avoid closing the listener after accepting the
incoming connection. It's not necessary to explicitly service the
listener further, since the OS listen queue is sufficient to accept
the additional connection.
Closing the listener at drain time is almost acceptable, but still
occasionally fails due to the fact that drain() is (necessarily)
called before remove_device(). Not explicitly closing it at all is
acceptable, since Python closes it as part of the object cleanup.
TESTED:
Ran regress-driver in TCP mode with a 30ms WRITE_PAD on all logfiles
on three versions of OSX, as well as Linux, FreeBSD, and OpenBSD, both
with and without the fix. Observed spurious errors in all cases
without the fix, and no cases with the fix. Also verified that no
dangling sockets were left at the end of the runs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current method for assigning ports uses a counter initialized to a
constant. Although this works fine for multiple sessions managed by a
single instance of fake.py, it fails miserably when running multiple
parallel instances of fake.py. The fix is to allow the OS to assign
the port numbers, since it's guaranteed to pick unused ports.
In the TCP case, this is simply a matter of specifying 0 as the port,
and then extracting the actual assigned port number with
getsockname().
In the UDP case, it's more complicated since the port number being
picked is actually for *gpsd's* end, which can't be done in a
straightforward manner. The workaround, which was already being used
to pick the control-socket port for gpsd, is to bind a socket with a
reusable address, close it, and then assume that the port will remain
available until gpsd grabs it. This change turns the existing code to
do that into a function, with the socket type now being specifiable.
TESTED:
Ran all daemon tests in both TCP and UDP modes, on three versions of
OSX as well as Linux, FreeBSD, and OpenBSD. Used default WRITE_PAD
values except on OSX, where it was reduced to 1ms to save time.
Signed-off-by: Jon Schlueter <jon.schlueter@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
large scale autopep8 cleanup of several
pep8 whitespace warnings
|
|
|
|
|
| |
Before this fix, satellites from the Beidou or QZNSS wuld have been
incirrectly displayed with the SBAS shape.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
When gpsfake is run as root, it may, depending on OS configuration,
create the pty's with 600 permissions that gpsd can not later read.
Make fake.py create all pty's permission 666. Solves the problem
running scons check as root on Gentoo and OS X.
|
| |
|
|
|
|
| |
No logic changes. All regression tests pass.
|
| |
|
|
|
|
| |
All regression tests pass.
|
|
|
|
| |
All regression tests pass.
|
| |
|
| |
|
| |
|
|
|
|
| |
All regression tests pass.
|
|
|
|
|
|
|
|
|
| |
Regression tests pass with nonblocking I/O, but a regression test *rebuild*
fails with timing errors. Much as we want a solution to the select-buzz
problem, this change must go on hold until the root cause of the timing
problems is found and fixed.
Regression tests still pass.
|
| |
|
|
|
|
| |
This commit has no semantic change, just housekeeping.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This makes the -f option of gpsfake obsolete, and it has been removed.
All regression tests pass.
|
|
|
|
| |
All regression tests pass.
|
|
|
|
| |
All regression tests pass.
|
|
|
|
|
|
| |
Also, zero in on shorter delays in the regression tests.
All regression tests pass.
|
|
|
|
|
|
|
| |
This addresses the buzzing-select problem, but the cost is that the GPS
regression tests require longer delays and may hang if the delays are too short.
All regression tests pass.
|
| |
|
|
|
|
|
| |
It seems NetBSD-5 has different behavior than 6. Add a new if branch
for 5 with longer delays.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is a comment-only change. It notes that OS X regression tests
fail, even with long times.
|
| |
|
| |
|
| |
|
|
|
|
| |
All regressions tests pass.
|
|
|
|
|
|
|
|
| |
...actually revealed a bug - device-shutdown messages getting lost on the
way out to the test clients. This set of changes mostly fixes it. Some
glitches remain; this state of things passes all regression tests but
attempting to get rid of what now ought to be unnecessary code in fake.py
does not pass. To be continued...
|
|
|
|
| |
All regression tests pass. PPS is live.
|
|
|
|
|
|
|
| |
again."
It breaks regression testing (but not the production code).
After this revert all regression tests pass again.
|
| |
|
| |
|
| |
|