- User Since
- Oct 2 2015, 1:17 PM (184 w, 6 d)
Tue, Apr 16
Mon, Apr 15
Fri, Apr 12
Would iflib like any kind of UPDATING or relnote mention for the generated 'stable' MAC address likely changing (since we're restricting the range now to a subset of the FF OUI), or is it fine without explicit mention?
Thu, Apr 11
Wed, Apr 10
Tue, Apr 9
Any other comments?
Mon, Apr 8
Thu, Apr 4
Wed, Apr 3
Mon, Apr 1
Sun, Mar 31
Excellent, thanks! Will commit when I get a chunk of free time tomorrow night (for reference, ~22 hours from now)
Fri, Mar 29
Thu, Mar 28
- Stripped iflib.c of some headers it no longer needs
- Pulled out the _masked version of ether_gen_addr; the envisioned other consumed will not be using it, so there is no need.
- Revised comment to match suggested wording by jhb.
Any further input on this latest iteration?
Tue, Mar 26
Change is good; please do go ahead and include a bectl test, referencing the PR in the test's descr.
Wed, Mar 20
Tue, Mar 19
Mar 17 2019
Abandoning for this now; further contemplation leads me to think my local hack should stay local on this one. I do think there's a tangentially related problem here, though, that I'll likely address in a different review: consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 that gets forwarded *through* em1 will increment bridge0 IPACKETS/IBYTES and get passed through bridge0 bpf. Unicast traffic specifically for em1, though, will *not* have any of this accounting done and not get passed to bridge0 bpf, just em0 bpf, despite still having passed over the bridge in the same fashion. It strikes me as incorrect to treat this traffic any differently than in the bridge_forward case.
Mar 15 2019
Here's a second stab at it. Highlights reel:
- Changed terminology from random -> generated
- Threw in some commentary about expectations
- arc4random -> SHA1 w/ hostuuid and if_xname (to start with...)
- Converted iflib to using the same mechanism since we're leaning towards "there's nothing wrong with these always being deterministic"
Correct slight oversight: don't double-tap packets that are being received by the same interface that they came in on. Those take the same path.
Commandeering to abandon in favor of D18856
Mar 14 2019
Push vnet context up into the callout callback
I'll drop in to provide some initial review within the next couple of days, now that I've done a bit of dabbling in the area. Apologies for the delay.
Sorry, did the dumb there... ripped out the explicit teardown of the clones, since that actually happens. bridge_rtnode_zone remains virtualized, because that's still the cleanest way -- the clones get destroyed upon if_clone_detach, which happens after the MOD_UNLOAD event.
I guess I should mention that my original example isn't actually accurate to what I'm doing -- I've got an interface like OpenBSD's if_vether that I'm throwing in the bridge rather than em0. That doesn't work for other reasons, but it was clear that the panic was legit.
Mar 13 2019
Mar 12 2019
Mar 11 2019
Mar 6 2019
Tagging @bdrewery as well, since I'm hooking this up to the kernel build. A glance over to make sure I'm not doing anything too terrifying would be appreciated.
I guess while you're addressing those, you can go ahead and upload a version that has the mtree addition with it, too. =-) ^/etc/mtree/BSD.tests.dist just needs the two-line addition to make test installation work out.
That's odd, but not a problem -- I'll do a final pass over this tomorrow and commit, but it looks good at a glance.