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.

i am not 100% convinced this is a hardware problem since Linux appears to enable MSI-X by default, but either way it doesn't work.

In D50558#1154278, @ivy wrote:

In D50558#1154277, @zlei wrote:

@ivy Any details which parts have the same problem ?

it was reported on AR8171:

alc0@pci0:3:0:0: class=0x020000 rev=0x10 hdr=0x00 vendor=0x1969 device=0x10a1 subvendor=0x1849 subdevice=0x10a1
vendor = 'Qualcomm Atheros'
device = 'QCA8171 Gigabit Ethernet'
class = network
subclass = ethernet

i am not 100% convinced this is a hardware problem since Linux appears to enable MSI-X by default, but either way it doesn't work. (i spent a long time looking at this originally and could not work out what Linux was doing differently, and hardware documentation seems to be unavailable.)

Looks good to me.

User reports indicate that at least some other AR81xx parts have the same problem

I do not have any hardware to test this change, but it appear to be a regression by mistake.

Generally looks good to me, despite the order of the new option -j jail.

Also add @dfr as reviewer. I guess he will be interested with this feature :)

Looks good to me.

I think this change is not necessary, but the comment should be revised instead. Is there any issue caused by referencing a released ifa ?

Looks good to me.

In D49358#1125631, @glebius wrote:

This looks correct to me.
Does it fix any uninitialized af_data races? If it does, that is a strong MFC candidate.

Generally looks good to me.

I think that is a good approach. I have ever ( about 2020 ) tried to find ethernet switches supported by FreeBSD and finally found them in the src. It will be better to have them mentioned in the website.