MIPS hardware?

Robert Edmonds edmonds at mycre.ws
Tue Apr 12 19:24:20 UTC 2016


Evan Hunt wrote:
> A patch was recently submitted for BIND to fix something related
> to MIPS architecture.  ISC has no MIPS systems to test the patch
> with, and it seems worrisome to apply it without at least smoke-
> testing it. I wonder aloud if anyone has a MIPS system that I could
> briefly borrow the use of?

Hi, Evan:

Is this related to the BIND atomics implementation? (I think that's the
only architecture specific code in BIND?)

That particular code has been heavily patched at least by Debian, see
the following bug reports for details:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406409

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516616

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778720

I think the patch in the latest bug report is the best version, but
unfortunately it hasn't been integrated into an actual Debian package
upload by the maintainer.

I would highly recommend reviewing the differences between the BIND
mainline and the Debian patches, and between the patch that was
submitted to you and the Debian version. (I would check myself but AFAIK
ISC still has a closed-to-the-public bug tracker.) Assuming the patch
that was submitted to you is not actually the same as the Debian patch
:-)

If you do find some MIPS hardware to test on, make sure it's a multi-CPU
system, BTW.

There are a number of machines operated by the Debian project that I
have access to that I could run test code on for you (I can't give you
access myself, though). Any machine listed here:

    https://db.debian.org/machines.cgi

with "porterbox" in the "Purpose" column and "mips.*" in the
"Architecture" column would be useful, I think. But I don't have root
though, so the smoke-test would need to be able to run as an
unprivileged user.

By the way, there was a thread on this list earlier in September 2015
about using C11's stdatomic.h, and you mentioned opening a ticket to add
support for that. Any progress on that? I think at this point with years
and years of experience with buggy atomics assembly code (not just in
BIND but across every C project I've seen that tries this) it makes more
sense to switch to the compiler intrinsics.

And, uh, maybe an awkward question: If ISC doesn't have any MIPS systems
to test on, maybe the code should either be deleted, or disabled by
default (if there is a fallback), or a warning message printed at
configure-time, etc.?

Performance wise, it makes sense to me to target the fastest
architectures (late-model x86 and POWER >= 8) with whatever speed hacks
are necessary like atomics, to squeeze as much performance as possible
out of those systems. But every other architecture is so much slower
that people aren't running those systems for performance reasons, so
they should get architecture-independent fallback code that can be
tested for correctness on other systems. IMHO.

-- 
Robert Edmonds


More information about the bind-workers mailing list