libnvme API review

Daniel Wagner dwagner at suse.de
Wed Mar 18 05:07:10 PDT 2026


On Tue, Mar 17, 2026 at 11:10:06PM +0000, Ballard, Curtis C (HPE Storage) wrote:
> With this style and goal in mind something like the name Keith Bush suggested
> in a little bit later message makes a lot of sense to me. His suggestion of
> "nvme_do_subystem_reset" would follow the kernel's naming scheme while 
> the NVMe action that is performed matches the NVMe name.

Which other function would get the nvme_do_ renaming?

[lib]nvme_do_subsystem_reset
[lib]nvme_do_ctrl_reset
[lib]nvme_do_ns_rescan

[lib]nvme_submit_admin_passthru
[lib]nvme_submit_io_passthru
[lib]nvme_get_nsid

> >The only way I currently see to resolve this is by using a different
> >prefix for the library APIs (e.g., libnvme_) and reserving the nvme_
> >prefix exclusively for NVMe spec APIs. However, I am unsure if this
> >approach will reach a consensus here.
> 
> This approach looks like a really clean and easy to understand split to me.
> That sounds like it would mean more renaming though.

Christoph is also in favor this change. So if no one objects, I'll go
ahead and update those interfaces accordingly.

Any opinion/suggestion on the prefix name?

- libnvme: probably the one which wont conflict with anything else
- libn: too close to libnl (netlink)
- ln: too short?
- ...

While a bit long I'd say libnvme is likely to cause the least problem in
the long run. 



More information about the Linux-nvme mailing list