Re: [gpsd-dev] massive regression failures

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> 
> "Eric S. Raymond" <address@hidden> writes:
> 
> > And, right after it, write the equivalent and properly conditionalized test
> > for NetBSD.  I tried to google a list of NetBSD device numbers so I could
> > do this myself, but didn't find one.
> 
> You didn't find that, I think, partly because device major numbers are
> different per architecture, and partly because names in /dev are
> supposed to be an abstraction.  And even the linux case statement is
> pretty icky with magic numbers from someplace.  Are you sure those don't
> change across architectures?  At least long ago it seemed even types in
> headers did.

I'm pretty certain they're arch-independent.  If they weren't, we'd have
seem the failure you reported on Debian porterbox tests, much sooner.
 
> I'll see if there's some way to deal with this.
> 
> But in the meantime, it seems that the default assumption before the
> ifdef linux should be something that results in safe beahvior.  I'm
> doing a test run with the default at sourcetype_unknown, which feels
> more correct than assuming a character device we don't know about is
> rs232 (by which you presumably mean "acts like a real serial
> port/UART").  However, tests fail, probably because the adaptive delay
> is done for !pty, rather than specific types that need it.

That's right.  The actual test is !pty && !udp, but that's OK because UDP
device detection is done (reliably) elsewhere.
 
> With this, tests seem to be running ok so far:

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.

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.

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

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?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature