Yeah, you're right, I've been neck deep in linux and internal OS regulatory domain stuff too much recently :(

Let's look at the maxpower more carefully!

err? ok, let me go and re-revisit this again.

In D28122#628804, @arichardson wrote:

Seems fine to me, but I do wonder if this means that we have some UB that clang could also exploit in the future and generate crashing code. Any idea which function the first crash is inside?

• Update to only do this with GCC
• Add comment

(I haven't forgotten about this; I only just got mips32 to boot again...)

In D27778#623889, @koobs wrote:

In D27778#623886, @adrian wrote:

hi!

In D27778#620891, @bofh wrote:

In D27778#620866, @koobs wrote:

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

All qemu-* ports needs to be updated.

Can I just try to land this one first, and worry about the others later? I'd at least like to see a working qemu port with user networking available for other freebsd users to test with.

Sure, let's just follow this changeset up in a timely manner so all ports are consistent

Re PORTLINT output, these ones at least should be addressed:

WARN: Makefile: you may want directory for dependency sphinx-build to be textproc/py-sphinx@${PY_FLAVOR}
WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.

Portlint output:

In D27778#620891, @bofh wrote:

In D27778#620866, @koobs wrote:

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

All qemu-* ports needs to be updated.

ryan - I'll push this later today, but i figured you would want to see it as well :-)

Add portrevision

In D27608#616994, @imp wrote:

Can you get this accepted upstream?

In D27505#615262, @hselasky wrote:

@melifaro : Did you have any more time to look at this? I guess we need to be backwards compatible and possible need to have a pool allocation for all interface names starting with "vlan" only? Other interface names are excluded from the unit management.

Whoops, remove another cast

Updated to reduce casting and use better variable types

Update from markj

update based on comment from brooks@

Hm, wanna see if it compiles using gcc-6 instead? mips32 SHOULD compile now, as long as you disable ZFS.

Hm, how's this work on mips32? Has anyone spun this up in qemu on malta+mips32?

Update with imp's comments

Fix!

whoops brb

hi! please lemme know what you think!

who has test hardware that can test this and report back?

I've fixed the warnings here - https://reviews.freebsd.org/D26839

1. Updating D26804: [gnuregex] Fix size demotion rounding errors that have crept up with later gcc #
2. Enter a brief description of the changes included in this update.
3. The first line is used as subject, next lines as comment.

• it fails on 32 bit compilations and we don't special case libnetmap to only compile on 64 bit platforms
• it fails on 64 bit platforms when compiling lib32, which blocks the amd64 buildworld
• since nr_options is a uint64_t and we're using it as a pointer type, we really should not be assuming pointer == sizeof(int type) like this