net80211 has a whole chunk of things you can set when raw tx'ing frames via BPF. I think this is fine!

In D31215#702999, @avg wrote:

@adrian , in my opinion two things guarantee correct operation:

• the current element can never be removed (thanks to in_use)
• an iteration is always done with the lock held

So, whatever perturbations might happen while the lock is dropped, they should settle down before the next iteration.

In D31215#702973, @avg wrote:

@adrian , I thought that I took care of that via the in_use flag.
Could you please look again?

in general I agree with "push it into a thread", especially since we want to support LED blinking on things like behind an i2c bus, but the unlock;func;lock thing without checking the list has changed or the LED itself has been deleted is problematic to me. Yes, sure, the race is tiny and it only affects things if we're modifying the list at the same time we're doing some work, but surely we can handle that case. :-) That's why it was locked in the first place!

Oh I get it. DELAY(1) is delaying for one microsecond, which is too slow for what we're doing here.

Good catch!

nuke iiit

Yeah, I was thinking the same thing. It gets a bit unfun when we start looking at how we drain this versus direct dispatch, but let's tackle that later.

Nah, this already landed a long long time ago.

lol! this is old!

i mean, ok, until i move them into base proper :-P

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