no K&R in new code

sys/param.h is always first and in this case should replace sys/types.h. Also, style is to sort headers and not really break them up into blocks like this.

Not your fault, but device_register is horrible. It is completely iflib specific and shouldn't have the generic name it has. Also, it seems there should be a template iflib driver you can inherit from as a template that has the various device_foo methods mapped to iflib_device_foo so you don't have to duplicate all that.

So why not use this always?

Why are there two driver_t's and two devmethod arrays? Can't there just be one?

Normally attach isn't really a hot path such that we sprinkle __builtin_expect(). In FreeBSD we only use that in places where it actually matters (and ideally with some kind of measurement to show that it matters)

Much better to export these as sysctl nodes.

Having a constant for this register would be nice along with constants for the subfields, or at least a comment in the header explaining what the subfields are.

Having this be part of a 'alloc_regs' function is somewhat confusing. (pci_enable_busmaster means "I want permission to initiate DMA"). Most drivers just inline this into attach anyway without a subroutine. You could at least move pci_enable_busmaster directly into attach.

Most drivers don't bother doing this on detach.

Is this even used? The C file uses a 'pci_vendor_info_t'?

Did you mean to define a global variable in all the files that include this?

Debugging leftover?

These macros do seem to be a bit of an obscure way of dealing with a 'struct mgb_ring_info' defined in the #if 0'd comment.

Appears completely unused.

Almost certainly not :) That said only if_mgb.c will include if_mgb.h.

Aside, I noticed Linux drivers typically do not prefix register definitions etc. in their driver .h file, presumably because it will only be included by the driver itself.

This is how all the other iflib drivers do it but I think they could be combined.

Yes, all of these are obsolete.

They were defined prior to having multiple dma queues. If we revert back to a single dma'd block (which is preferable) then they might come in handy. I defined the macros because I don't think the struct would work quite the way we would want since it requires allocating extra space for the pointer.