gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] massive regression failures


From: Greg Troxel
Subject: Re: [gpsd-dev] massive regression failures
Date: Fri, 23 Jan 2015 11:55:19 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.4 (berkeley-unix)

"Eric S. Raymond" <address@hidden> writes:

> That's good. Looking at paths is a bit ugly, but probably not as
> brittle in general as looking a device major numbers.  I'd change the
> test to do this on Linux, but the magic-number checks are time-tested
> under Linux and I'm reluctant to disturb that code close to release.

That's fair enough for that case, but you might add a "this is not a
good role model" comment :-)

> Oh, you just gave me an *excellent* idea.  I'm adding this arm before the
> device-number checks:
>
>     /* OS-independent check for ptys using Unix98 naming convention */
>     else if (strncmp(path, "/dev/pts/", 9) == 0)
>       return source_pty;
>
> That'll catch any conforming Unix, including Linux if the present
> device numbers go sproing.

NetBSD has that too in newer releases, so that will help.  I just
haven't switched to it yet and forgot while writing what I did.

> How general are your paths to *BSD variants?  Could we use your code
> for, say, Mac OS X?

OS X is semi-BSD and semi-Mach, with extra Apple gratuitous
incompatabilities...

On OSX: It turns out /dev/ttyp and /dev/dtyp are present, though (with
major 4/5 vs 5/6 on NetBSD), so including that if on OSX should help.
PL2303 devices show up as /dev/tty.PL2303-[hexcrud]; the driver isn't
built in.

I suspect that enabling what I wrote on normal BSDs (Free, Open, Dragon)
as a starting place is probably better than not having it.

> An interesting question of method:  I could skip the delay if the device
> type check returns source_unknown.  That means the test would fail safely
> on platforms where sourcetype() doesn't work.  But...I think there's an
> argument that it is better for this to fail noisily so people doing
> ports will notice this and fix sourcetype().  Opinion?

Given that the delay is about energy consumption in some places, it
seems better not to break on other places.

Also, the regression tests failing due to the delay issue is a) a
non-obvious syndrome and b) masks any other failures.  So I think you
should instead add a test to check that sourcetype worked, somehow, and
have that not break the rest of the tests, but just get reported.
Essentially, I'm arguing that a single test failure pointing this out is
fine, but failing 81/89 is not.   This is related to the fact that if
any of the 89 tests fails, the rest of the tests don't get run, which of
course is not about this change but it's convenient to rant about it
now.

Attachment: pgpxiDWEpkMvD.pgp
Description: PGP signature


reply via email to

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