Humm, I'll see how broken that is. It might be nice though if we fixed the BROKEN_OPTIONS for NVME to blacklist the known bad arches as right now we don't build nvmecontrol on riscv64 but do include device nvme in GENERIC on riscv64.

I'll have to make all the nvmf modules follow the same rules, and right now they build fine on all arches. It would be simpler if we could just build everywhere. :( At least the manpages should probably honor MK_NVME instead of being hardcoded for specific architectures.

Oh, nvmecontrol was trivial fixable for armv7 and powerpc. It already has a hack to use uint64_t in place of uint128_t and I just changed it to apply that hack on all 32-bit architectures.

And actually, I can fix nvmecontrol to not be so dumb. It already fails to handle big-endian properly regardless and it really isn't hard to fix.

Well, not truncating values is a bit hard to fix actually, so I'll just let it truncate values on arm and 32-bit powerpc.

In D44690#1018882, @jhb wrote:

Well, not truncating values is a bit hard to fix actually, so I'll just let it truncate values on arm and 32-bit powerpc.

Yea. I have code under review to make them compile... but I haven't used nvme on these platforms. This tells me they are completely untested on those platforms which makes me nervous. Compilers don't support int128 enough..

I have the big endian fix too since i had to touch all the log page code to shift it to the user of the page's responsibility to convert the endian to host.

https://reviews.freebsd.org/D44650
and
https://reviews.freebsd.org/D44651

are the reviews that I'd already done. It's how I knew nvmecontrol didn't build there :).

We'd also need to change sbin/Makefile to build nvmecontrol everywhere.