A snd_hda driver is split into multiple child devices but there's only one PCI device with one interrupt handler. The child devices are just the way the driver organizes itself internally but they aren't real devices if you ask me. They all share the same lock for example. The bus_*_intr interface isn't used.

Use DRIVER_MODULE_ORDERED

It's just to respect AR and CC. I discovered this on a system where everything is built with ports llvm (no base system compiler installed).

In D50393#1152501, @christos wrote:

I haven't tested this for a few days, but I remember that even without the Makefile change, things worked as expected. Is this not the case?

Yes, when unloading a kernel module the drivers defined with DRIVER_MODULE appear to be deleted in reverse order.

Drain callout and taskqueue before shutting down child devices

In D46502#1066069, @jrtc27 wrote:

I've submitted a patch for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281674.

Well that doesn't even do MACHINE, which is important, otherwise you'll end up with MACHINE not matching MACHINE_ARCH, which breaks things. You can't in general just set one; that's a custom feature of the src tree's Makefile.

In D46502#1060031, @jrtc27 wrote:

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.