I would maybe note explicitly in the commit message that some impending magic will use this move to define it correctly for untied module builds, but I don't feel strongly about it.

In D37083#842126, @pstef wrote:

But the summary contains the same phrase twice, seems unintentional.

Awesome, thanks! IMO you've done sufficient testing to rule out obvious harm; MBR gets caught in the wildcard and uses the exact same /etc/fstab contents as it did before, so I think we can safely say this is good. I'll give it a ~day or two for someone to object or bring up some scenario we hadn't considered before landing it.

In D32936#841641, @allanjude wrote:

The reason we stopped doing this originally, is that if ZFS imports the pool using disk names like /dev/ada0p3, then the GPT label version like /dev/gpt/swap went away, and then you ended up with no swap mounted.
I don't know if things have changed somewhat since when I ran into these problems around 2015. I know there was some work to try to mitigate the issue.

I think this generally looks good, though I have a minor suggestion for you to consider...

Re-scope import to just wireguard-tools/src

In D36909#838277, @glebius wrote:

IMHO, code should be cleaned up from __FreeBSD_version and only code that is for CURRENT shall end in git branch main.

@jrtc27 noted a couple issues with alt_timeout... OTOH, would there really be any objections to mv /usr/bin/timeout /bin?

LGTM, modulo s/qutoes/quotes/ in the subject line. Thanks!

Switch to Andy's idea; do fdt setup in a new function entirely, just return
ENXIO if neither setup succeeds.

In D36776#834870, @cperciva wrote:

I always use GENERIC in EC2, but this seems accurate as far as it goes. Maybe you want to throw in an explicit device nvme as well since that's what modern EC2 systems use? But (as with acpi) that's something people are likely to have anyway.

In D36764#834496, @markj wrote:

Seems harmless to me.

other than the fact that I can't figure out how to make that change.

Does it not work because bus_space_tag_t is a pointer on some platforms but not others?

Second round of review feedback; rebased on top of Andy's pmap bootstrap cleanup
branch.

Address review feedback.

I also still haven't put too much thought into why arm64 KASAN seems to use way more stack than amd64 KASAN.