uapi/linux/nvme.h

The NVME UAPI header contains a lot more than just the controller definitions - it's basically the whole NVME command set.

Any reason for this? IT's very unlike what we do for ATA and SCSI, and fairly dangerous as we now need to make all changes to the command set headers in a way that wouldn't break userspace software.

Yep, this was to provide user space all the nvme definitions, but tools often redefine their own nvme commands and structures, and use the uapi header only for the ioctls.

I'll stop adding new stuff here if the kernel driver isn't explicitly using it, but should we remove everything it's not currently using?

In theory we should never break userspace, but given how relatively recent NVMe is we might try to get away with it (the rule is you can break userspace APIs if no one notices..).

If people notice and complain we can set the current defs in stone under #ifndef __KERNEL__.

There is an NVMe test compliance suite developed at www.iol.unh.edu (U of New Hampshire that has hosted NVMe plugfests), that will probably be one of the first things to check to see if changes in here break. I have no experience with this test suite; I just know it exists.

Do you mena this one: https://github.com/nvmecompliance/tnvme/

It doesn't seem to use our nvme.h heaer for anything. In fact it seems to use totally non-standard ioctls not provided by the in-kernel nvme driver.