mi: Cleanup nvme_mi_mi_config_get() to nvme_mi_get_mi_config()

[ikegami-t]

No description provided.

[ikegami-t]

Changes for the issue #206.

[igaw]

@jk-ozlabs

[igaw]

My take on this, we will do this type of work for a major version update, e.g. libnvme 2.0.

[jk-ozlabs]

Nack on this one. The nvme_mi_mi_ prefix is intentional: we use this for all of the nvme_mi_ functions that send MI-type messages. So we have:

• nvme_mi_mi_ for the MI commands sent over MI; and
• nvme_mi_admin for the Admin commands sent over MI

This is documented at:

libnvme/src/nvme/mi.h

Lines 35 to 44 in 42ac453

	* A couple of conventions with the libnvme-mi API:
	*
	* - All types and functions have the nvme_mi prefix, to distinguish from
	* the libnvme core.
	*
	* - We currently support either MI commands and Admin commands. The
	* former adds a _mi prefix, the latter an _admin prefix. [This does
	* result in the MI functions having a double _mi, like
	* &nvme_mi_mi_subsystem_health_status_poll, which is apparently amusing
	* for our German-speaking readers]

[igaw]

True, I forgot that we already discussed this. Let's keep it as it is.

[jk-ozlabs]

(and the config_get is a direct reference to the MI Configuration Get command; not sure if we want to apply the verb-noun ordering to this one...)

[ikegami-t]

Thanks for your comments. I could understand them. By the way seems the PCIe commands over MI not implemented yet. (Also seems the mi resp status NVME_MI_RESP_PCIE_INACCESSIBLE is for the unimplemented command.)

[jk-ozlabs]

Yes, that's correct - I haven't done any work on the PCIe command-set. It's optional in the spec, and I don't know whether any of the device I have actually support it!

Is this something you're looking for, to be implemented?

[ikegami-t]

Thanks for the confirmation. No I thought to confirm if just my understanding for the PICe command-set support implementaton is correct or not. (I am also not sure if my device supported it.)