In D45572#1040231, @emaste wrote:

In D45572#1040228, @zlei wrote:

Shall we at least mention the previous well-known terminology CMOS clock ?

I have The Real-Time Clock may also be called the CMOS Clock. -- do you think this is insufficient?

Oh, my fault. I did not read carefully. I'm OK with that.

In D45585#1040016, @kp wrote:

Open question: when do we commit this? Now, in advance of 15.0? As soon as stable/15 branches, so that it will first arrive in 16.0?

I'd argue we should do it now (i.e. so that it'll be part of 15.0).
The warning has been present since 13.1, so that's two full major releases of warning (on top of the fact that not specifying a mask has been a bad idea since about 1993). That seems plenty long enough.
And if we're going to do it for 15 we should include this change sooner rather than later, so that there's more time for people to notice any fallout before the release.

Shall we at least mention the previous well-known terminology CMOS clock ?

It is definitely the right fix.

Allow iovctl to create VFs that are restricted to specific VLAN IDs.

So will the restricted VFs work much like vlan(4) devices over PF ? Or vlan(4) over VF is still needed to pass in tagged packets to the net stack?

In D45283#1033101, @kp wrote:

diff --git a/tests/sys/net/if_vlan.sh b/tests/sys/net/if_vlan.sh
index 675ed0090e8c..4d5d70410898 100755
--- a/tests/sys/net/if_vlan.sh
+++ b/tests/sys/net/if_vlan.sh
@@ -37,7 +37,7 @@ basic_body()
        # And change back
        # Test changing the vlan ID
        atf_check -s exit:0 \
-           jexec singsing ifconfig ${vlan1} vlandev ${epair_vlan}b vlan 42
+           jexec singsing ifconfig ${vlan1} vlan 42 vlandev ${epair_vlan}b
        atf_check -s exit:0 -o ignore jexec singsing ping -c 1 10.0.0.1
 }

is probably enough for a test case.

Looks good to me.

I guess I need a better Title for this CR , I dislike the redo ...

In D45196#1031264, @jhibbits wrote:

Given that all(?) other ethernet drivers unconditionally ETHER_BPF_MTAP() (so, ether_bpf_mtap_if())

@khng I think with this change even shadowing those global variables can be easily caught.

In D45197#1031659, @gshapiro wrote:

Just a quick note that the PR listed on this is incorrect. This fix addresses PR 278394.

This is split from D40467 with fixing the order of .fini_array section.

I tried to Update Diff but failed. Split the definition for other platforms to D45214 .

Should ready to go.

@aokblast
I'm not familiar with debuggers, so this might be a silly question.

In D45196#1030920, @kp wrote:

The referenced commit (2b9600b4497b) seems to be relevant for the detach flow, but it doesn't guarantee there will an if_bpf pointer when a struct ifnet is created.
However, ether_ifattach() does an unconditional bpfattach(), so I think this is still correct (given that mlx* are Ethernet devices).

In D45196#1031138, @kib wrote:

These two seems to be the only uses of if_getbpf() in the tree, unless I mis-grepped. Is this the cause for the change?

In D42391#1031131, @adrian wrote:

I'm sure I've seen FCSes in 802.11 bpf traces? Maybe that's happening at the 802.11 radiotap level?

In D45194#1031125, @imp wrote:

Then a quick line in yhe commit messafe saying its a fix

While Linux does support tap traffic without good CRC (FCS) via tcpdump / bpf. I think that is most useful for developing drivers / hardwares or diagnosing noisy wireless environment, but I think that (enable capturing bad CRC via bpf) should be turned on per interface and still those packets with bad CRC should not enter net stack. So I'm convinced this is the right approach.

In D42391#1030031, @emaste wrote:

This is a breaking change. 3rd party drivers should take care of it.

It's fairly straightforward for 3rd party drivers to chase this tough, I don't think it's a big concern.

In D45194#1030970, @imp wrote:

Other arch? At the very least a lube in the commit about why not relevant there

@kp has just made similar fix 59a6666ec91d for if_ovpn.

Split the FIX for sorting input sections to D45194 .

Xref a PR: 271344 which was reported after the fix.

The change is simple and looks good, IMO manual test is required at least.

Looks good to me.