The change to in6_getlinkifnet() looks good to me.

In D51451#1174919, @kbowling wrote:

I would remove the phrase 'change will not fix anything but' in the commit message and I think this is good.

In D51451#1174756, @kbowling wrote:

In the commit message do you mean to say there is something else double counting?

Looks good to me.

In D51351#1173150, @kp wrote:

A bit late, but Steve confirmed this fixed the freeze with ifconfig when the SFP is not plugged in.

Open for review to see if someone has better knowledge about this parameter.

In D50947#1171980, @glebius wrote:

In D50947#1171973, @zlei wrote:

P.S. Why do you want to merge that to a stable branch?

The structs has __packed attribute so it is unlikely to have wrong size. Well I'm a little paranoiac that may happen in some way :)

It is not about observing a different size, but about the _Static_assert() not being support by some compiler with some flags. The risk is low of course. But practical benefits of having change in STABLE are also very low.

In D50947#1171749, @glebius wrote:

Please include the link to the exp-run bugzilla into the commit message.

P.S. Why do you want to merge that to a stable branch?

The exp-run looks good. Any objections ?

I like the word noclamp. Well, there're other tunneling interfaces such as if_gre, if_vxlan and if_wg. Will we introduce too many XX_NOCLAP flags for other types of tunneling interfaces?

Looks good to me.

For hardware interfaces, the hardware address is a nature of the interface, regardless of its name or host uuid or jail name.

In D51067#1165467, @olce wrote:

That fence should be too much, and CK_STAILQ_INSERT_TAIL() is supposed to insert a proper store to store barrier, so this is probably a mistake, but if possible I'd like to know if that changes something in practice.

Generally looks good to me.

In D50947#1163620, @markj wrote:

In D50947#1163271, @zlei wrote:

In D50947#1162949, @markj wrote:

In D50947#1162925, @zlei wrote:

I intended to MFC this to stable/14, but stable/14 still has gnu99 as the default.

But this header is also used outside of the base system, isn't it? This could break applications using ethernet.h compiled with -pedantic -std=c99 -Werror, for instance. I'm not sure if any exist, but an exp-run would be a good idea IMO.

That is exactly what I concerned. Or I push this in main and later do exp-run before the MFCing ?

It would be better to do the exp-run first, I think. There may be enough failures that this change is not worthwhile.

In D50947#1162949, @markj wrote:

In D50947#1162925, @zlei wrote:

I intended to MFC this to stable/14, but stable/14 still has gnu99 as the default.

But this header is also used outside of the base system, isn't it? This could break applications using ethernet.h compiled with -pedantic -std=c99 -Werror, for instance. I'm not sure if any exist, but an exp-run would be a good idea IMO.

I intended to MFC this to stable/14, but stable/14 still has gnu99 as the default. Modern compilers used by FreeBSD support _Static_assert so for in-tree consumes the MFC should be safe, then how about the out-of-tree consumes ?

In-tree drivers will be cleaned up in following up commits. I intended to mention this behavior change in UPDATING, but 3rd party shall not be affected, if they FIX the header length after attaching the interface.