NBFT API overhaul#3583
Open
tbzatek wants to merge 7 commits into
Open
Conversation
Update the raw ACPI NBFT C type definitions to match the NVM Express Boot Specification Revision 1.3. Changes include: - nbft_hfi_info_tcp: hfi_ext_info, pcie_seg_num - Add NBFT_HFI_INFO_TCP_IPADDR_AUTOCONF - Add struct nbft_hfi_info_ext (descriptor type Ah) for HFI Transport Info Extended Information - Add enum nbft_hfi_info_ext_flags (VALID, DCI) - Extend struct nbft_ssns_ext_info with naed, cipeec, cto, nceec - Add enum nbft_ssns_ext_info_naed - Add enum nbft_ssns_ext_info_cipeec - Add enum nbft_ssns_ext_info_nceec Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Update the NBFT parser to handle both revision 1.0 and 1.1 NBFT files, and extend the convenient API with fields added in Boot Spec rev. 1.3. All new fields default to zero for rev. 1.0 NBFT data files. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Replace individual bool struct members in the nbft.h public API with raw enum bitmask fields that reuse existing enums from nvme-types-nbft.h. This prevents ABI breakage when future Boot Specification revisions add new flags to existing enums. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Update nbft-dump.c to print all struct members from nbft.h and regenerate all test diffs. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Update nvme.i to mirror the C API: expose raw flags instead of decoded bools. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Update the JSON output with added fields while preserving the decoded bools from the old API to avoid breaking the format. Took the liberty to fully parse the DHCP DUID identifiers into individual JSON keys. Not all JSON keys are printed all the time, those not applicable either due to an older NBFT file revision or optional and not present are not printed out. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
While we're intentionally not going to support Security Descriptors yet, the public API needs to be finalized before it gets stabilized and frozen for libnvme-3.0. Signed-off-by: Tomas Bzatek <tbzatek@redhat.com>
Collaborator
|
From a quick glance it looks good. Does every patch for itself compile? I think I saw code refactoring which will break the build, e.g. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a sync of the Boot Specification rev. 1.3 into
nvme-types-nbft.hand thenbft.hparser API.nbft.hdon't include any reserved fieldsnvme nbft showJSON output preserves all the original bool flags to maintain compability with dracutAssisted by Claude, it's surprisingly easy to let it craft synthetic binary NBFT table for testing, if needed.
Cc: @mwilck @stuarthayes @martin-belanger @johnmeneghini @MichaelRabek