Skip to content

libnvme/cmds: change copy desc format 0h and 2h elbt to big-endian#3183

Open
ikegami-t wants to merge 7 commits intolinux-nvme:masterfrom
ikegami-t:copy-elbt-endian
Open

libnvme/cmds: change copy desc format 0h and 2h elbt to big-endian#3183
ikegami-t wants to merge 7 commits intolinux-nvme:masterfrom
ikegami-t:copy-elbt-endian

Conversation

@ikegami-t
Copy link
Contributor

Since the format 1h and 3h elbt values are set as big-endian. Also change the field name eilbrt to elbt as following spec.

@ikegami-t
Copy link
Contributor Author

ikegami-t commented Mar 13, 2026

@igaw @keithbusch @brandon-paupore-sndk @zwxdg @chenghong085 Could you please review the changes? For the issue: #2975 I have rejected the PR: #2977 then the issue also closed. To make consistent just created this PR changes but for the changes I considered again so still the issue: #2975 mentioned seems correct also.. To make sure should we ask to NVMe org about this specification?
Note: I am thinking to change elbat and elbatm fileds also to big-endian to make consistent (but not sire sure if correct or not).

@igaw
Copy link
Collaborator

igaw commented Mar 13, 2026

Would it be possible to have a unit tests for this? Given the amount of discussion around this API I think it would be great to have one. Maybe we could get a binary copy of an existing log page and decode it then?

@ikegami-t
Copy link
Contributor Author

Okay will do try it later. Thank you.

@ikegami-t
Copy link
Contributor Author

Just created the separated PR: #3185 for the unit test.
Note: The test expected data is depended on the current API: nvme_init_copy_range if the API behavior changed then the data also needed to be changed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should rename this struct to nvme_copy_range_f0 because also the spec names this f0.

@igaw
Copy link
Collaborator

igaw commented Mar 16, 2026

Looks good. I saw that there are a handful of new fields defined in the newest spec. We might want to add them too. WDYT?

BTW, the commit message doesn't match anymore. This change updates the names of the fields.

@ikegami-t
Copy link
Contributor Author

Yes I will do rename the struct and add new fields by additional commits. Thank you.

Since the format 1h and 3h elbt values are set as big-endian.
Also change the field name eilbrt to elbt as following spec.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Since the elbt field changed to big-endian.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Change both the struct name and the init API names.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Just followed NVMe command set spec revision 1.2.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Just followed NVMe command set spec revision 1.2.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Just followed NVMe command set spec revision 1.2.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
@igaw
Copy link
Collaborator

igaw commented Mar 18, 2026

Sorry for my recent changes and you had to rebase your work. I'll just have to read up on the little to big endian change in your explanation. It strikes me a bit odd that one field is big endian, but that might just be my OCD...

Change odd big-endian field as same with the format 1h and 2h.

Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
@ikegami-t
Copy link
Contributor Author

No problem. The changes to move the nvme_init_* implementation to header look good. Just changed the odd big endian field to array as same with the copy range format 1 and 3.
Note: The x390x cross build error will be fixed later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants