libnvme API review

[Daniel Wagner]

Hi Chaitanya,

On Mon, Mar 16, 2026 at 05:32:00PM +0000, Chaitanya Kulkarni wrote:
> Based on the Curtis's comment if we follow this format we may not be
> compliant with spec, if that is okay with everyone then we should strictly
> follow the spec.

As I pointed out, we have to separate the NVMe spec related APIs from
the library APIs. These are two separate things.

> Otherwise
> nvme_[ACTION]_[COMPONENT] format is much easier to follow and keep it
> consistent across the whole code-base.

Going strictly this rule is an option but it would make the tree.h API
slightly less well organized, IMO. E.g. we have function which operate
on the namespace object:

    nvme_ns_get_csi
    nvme_ns_get_eui64
    nvme_ns_get_firmware
    ...
    nvme_path_get_ctrl
    ...
    nvme_ctrl_get_address

would then be

    nvme_get_ns_csi
    nvme_get_ns_eui64
    nvme_get_ns_firmware
    ...
    nvme_get_path_ctrl
    ...
    nvme_get_ctrl_address

Sure this works. I am not really attached to either way. If someone
really makes a strong argument to touch the complete tree.h API, I would
suggest to stick with the current solution.

> nvme_identify_controller()
> nvme_identify_ns()
> nvme_create_ctrl()
> nvme_create_ns()
> nvme_match_ctrl_config()
> nvme_get_subsystem() and
> nvme_reset_subsystem().

Yes, this is what I'd like to do (except for the tree.h part).

> It will be very inconsistent if we try to follow the spec since spec may
> not follow same convention (???).

I left out is the mi.h header. It strictly follows the NVMe spec with
gives some 'interesting' names. Though it's very simple to find the relevant
part in the spec.

> Keeping the naming convention separate from the spec and following
> above example format is much easier for long term nvme-cli future and
> maintenance.

In the other mail you argued it's good to stick to the same names. Did
you mean this for the nvme commands and the 'payload'?

Cheers,
Daniel