While I don't have an issue with this change per se, if the goal is to support nvme-cli, I'd argue that it would be better to provide an emulated device node via the Linux compatibility layer. The main concern is nvme-cli assumes it operates under Linux which exposes NVMe devices to the system in a very different way to what FreeBSD does (e.g. device node naming differences, device nodes are block devices, etc). Thus to better support nvme-cli, there would probably be additional IOCTL's added here to support / work-around Linux-isms. And these additions would look odd as nothing in base would use them.

In D22785#499016, @chuck wrote:

While I don't have an issue with this change per se, if the goal is to support nvme-cli, I'd argue that it would be better to provide an emulated device node via the Linux compatibility layer. The main concern is nvme-cli assumes it operates under Linux which exposes NVMe devices to the system in a very different way to what FreeBSD does (e.g. device node naming differences, device nodes are block devices, etc). Thus to better support nvme-cli, there would probably be additional IOCTL's added here to support / work-around Linux-isms. And these additions would look odd as nothing in base would use them.

I looked at going full support, and it would be a lot. The extra nodes, the different names aren't so bad, but it's the different semantics for similarly named nodes that was the deal killer. My nvme-cli port handles the differences a mix of stuff we do in the kernel and stuff we do in nvme-cli to handle the differences there. This is one of the differences I couldn't easily handle there.