libnvme API review

[Ballard, Curtis C (HPE Storage)]

Daniel,

Thanks for the response and additional context.

>Hi Curtis,
>
>On Mon, Mar 16, 2026 at 03:34:39PM +0000, Ballard, Curtis C (HPE Storage) wrote:
>> It looks like these proposed changes are intended to align better with the terms
>> in common use or in the NVMe specifications.
>
>I think I should provide some background here first.

Thanks for sharing all the background. I have spent some time reading the code
but I'm not in it enough to be really familiar with how all the headers files 
tie together so that was really helpful information.
 
>
> . . . As outlined in the email, the proposal is to
>adopt the nvme_VERB_RESOURCE pattern, which more closely follows the
>kernel's naming scheme (at least within the NVMe subsystem).

This is very clear to me: nvme_VERB_RESOURCE as the preferred pattern and more
closely following the kernel's naming scheme makes sense. NVMe terminology 
isn't even always internally consistent so using the kernel's naming scheme 
sounds like the right direction when not specifically referencing the NVMe API.

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.
 
>
>> The term in the NVMe specifications is "subsystem reset" and that term is used
>> many times but I don't see any use of "reset subsystem". Most common use by
>> those well versed in the technology also is "subsystem reset" though I have
>> seen "reset subsystem" used pretty frequently by people who aren't deep in
>> the NVMe specs.
>
>I see. The problem is that mixing NVMe spec terminology with library
>API terminology could cause confusion.
>
>> I don't know whether there is a 'best' for this term. General software developers
>> might prefer "reset subsystem" but mapping to the specs will be easier with
>> "subsystem reset".
>
>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.
>
>Thanks,
>Daniel

This approach looks like a really clean and easy to understand split to me.
That sounds like it would mean more renaming though.

Curtis