Add IOCTL to get device ID

[imp]

Summary

Add NVME_PCI_ID to directly get the PCI vendor, device, subvendor and
subdevice. nvme-cli can use this ioctl to report additional
information about the drives. Adding an ioctl to get this data is
easier than the alternatives.

[mav]

I haven't looked on it in Linux to compare, but I have no objections.

[chuck]

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.

[imp]

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.