Use memcpy

The arm assembly for the memcpy() variant is identical FWIW.

Yes, I like the memcpy version better.

Rebase on D54397

Pass tinderbox

Hmm, looking at the code both before and after this change on armv7, it is just using plain ldrh and strh which will fault on unaligned accesses?

I tried various permutations of alignas and that didn't work either. Also, alignas apparently can't weaken alignment, only strengthen it, and alignas can't be used in a typedef.

D53898 is a duplicate (not sure how I ended up with two of these).

I think those issues are not made any worse by your patch? And the fix is something that RISC-V and amd64 would need as well (well, RISC-V also needs this patch). I think you should just merge your current patch and let @markj fix both amd64 and aarch64 when he adds the new arena.

BTW, I've thought about adding an acpi_unregister_ioctl_all or the like that just takes the fn argument and unregisters all commands that use the same function. That would be a nicer way to handle unloading of a module that registers multiple handlers.

This is more of a RFC than a commit candidate. When I tried to use /dev/mem to access a register I got a "system error abort" panic (but mapping the same memory region with new-bus as a struct resource worked fine). The use case for me was using dd if=/dev/mem iseek=<register physical address/4> bs=4 count=1 | hd is how I got the SERR# panic. I'm not sure if the difference is that I should be using a different memattr perhaps? On amd64, this code uses pmap_kenter for the !can_fault case to avoid TLB shutdowns. I'm not sure that is as important for arm64 since shutdowns are presumably a bit cheaper which is why I did the lazy thing.

Ed noted that this file has grown very large, so this change trims it to only show entries for supported branches. In particular, if the goal (as I understand it) is to help porters know which versions to use when maintaining ports, then there isn't really a need to document values from unsupported branches.