Re: [gpsd-dev] Preparing for release

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> > Does anyone running on a Mac have any theory or insight about what's
> > going on?  Greg Troxel's reports seem to indicate that the first open
> > of Mac tty devices is doing something to them that is making later 
> > attempts to use them fail, but also that it is not the recent change to
> > blocking I/O. I've been hoping we could see before-and after stty
> > reports, but nobody has generated any.
> 
> I don't think it's a first open issue.  I tested also with a ublox 4
> eval board (old, from 2008), and it seems to basically work, even
> stopping/starting gpsd.  Something seems funky about ublox6 in
> particular.

While this is theoretically possible, I have two uBlox-6 based devices
I test with regularly (one GR-601W and one uBlox EVK-6H eval kit) and
they're as solid and reliable as granite with my Linux systems - a real
pleasure to work with.  I think the EVK-6H is my favorite piece of test
equipment ever.

We're also not getting this weirdness from *BSD systems other than OS
X, AFAIK, So if there's something funky about uBlox-6, it seems to be
specifically in interaction with the Mac.

> I now think that the sometimes-works-initially behavior is not about
> serial port reset issues but about catching the device at the right time
> in power up sequence.

By "the device", do you mean the GPS or the host-side serial hardware?

Because if you mean the GPS, then the salient question is why Linux
never hits this timing window.

> I also don't think it's necessary or reasonable to declare the Mac as
> "unsupported". 

Again, if there's something funky about uBlox-6 it's specifically in
interaction with the Mac.  And we have Frank Nicholas's report of
continuing Mac issues with a Bluetooth-based GPS, and we don't know
that the Mac PL2023 bug of 2009 was ever fixed.

It's not for one of these that I just took Mac OS X off the list, 
it's for all three of them.  I'm open to putting it back on if,
for example, we discover that there's some Mac-specific invocation
we can mutter that fixes the first two problems.

>      It's really just that there is a bug with at least a
> device or two and we don't know how bad the issues are, and it may be
> that the bug is in mac code instead of gpsd.   So just saying that seems
> far more useful.   I will try a few more devices.

If we think there are substantial odds of a Mac OS bug rather than a
GPSD problem, what alternative do we have to declaring non-support
until we know what's going on?  Shipping code that we know will be
flaky *and calling the platform supported* doesn't sit well with me.

I feel a need to be conservative about this.  People rely on GPSD for
life-critical uses; when we say a platform is "supported" I don't want
there to be any doubt or fuzziness about what that means.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature