Remove "make_ucode.sh" from a previous incarnation of the port.

I can't seem to get USE_QT5 to do anything with the OPTIONS_SUB framework. Does it work?

Switch top options helper and OPTIONS_SUB where possible. I still
am not clear on how to make USE_QT5 do the right thing in this
framework.

Drop the uneeded shell script and DTRT in Make to get a for
loop. :-)

Restore delete AMD cpu files.

Is this to be committed to head? Are the Intel folks going to fire this off?

At this point, head is running an IFLIB version of ixgbe(4) so this is not needed (shouldn't be anyway).

dumbbell@ has reported that this fixes his current problems with lagg(4) panicing on his hosts.

Appoved pending update for an iflib consumer.

Reusing existing bridge code for this is an excellent idea.

Tagging @gnn as he committed the original driver in 2011.

Committed r333388

Should be cosmetic and cleans up warnings only.

Deprecation notice has been merged to stable/11.

In D15326#323223, @imp wrote:

In D15326#323185, @sbruno wrote:

In D15326#322966, @imp wrote:

So why isn't sys/ctypes.h enough? you're introducing a dependency on userland inside files that look like they are used by the kernel.

Ugh. This didn't occur to me as this was part of the buildworld stage. How about I add a "#ifndef _KERNEL #includ <ctype.h>" type thing. sys/ctype.h doesn't have all of the same ctype macros that are in /usr/include/ctype.h ... so that might be a problem.

why doesn't sys/ctype.h work? We should fix that problem...

In D15326#322966, @imp wrote:

So why isn't sys/ctypes.h enough? you're introducing a dependency on userland inside files that look like they are used by the kernel.

This code no longer appears in the upstream version: https://github.com/illumos/illumos-gate/edit/master/usr/src/lib/libzfs/common/libzfs_sendrecv.c

I've sent a request to release engineering to MFC r333210 to the stable/11 tree as its frozen. After that is done, we can commit this.

Seems fair to me. Your debugging seems to indicate you've traversed the right paths to come to this conclusion.

Seems fine to me.

In D14969#321820, @shurd wrote:

SPARC and PowerPC get this:

--- in_mcast.o ---
cc1: warnings being treated as errors
/usr/home/admin/src/freebsd-base/sys/netinet/in_mcast.c:234: warning: function declaration isn't a prototype [-Wstrict-prototypes]

I've added the correct dates and will commit this.

Did anyone have the hardware lying around to test this one?

I've tested this quite a bit and am happy with the results.

Tested on:

chatted with @brooks in IRC.

Agreed on all points. This driver can continue to be used on FreeBSD 11, but has no business in FreeBSD 12.

In D15211#320576, @imp wrote:

while you're here, maybe it's time to do the uefisign -> efisign with a legacy link.