libnvme(2)

✨ NAME ✨

enum nbft_ssns_flags β€” the Subsystem and Namespace Specific Flags Field (Figure 16), bestie πŸ’–

Like, it's part of the libnvme API Manual, section 2, and it's literally the flag field that tells you what's up with each SSNS descriptor. No cap.


🌸 SYNOPSIS 🌸

enum nbft_ssns_flags {
    NBFT_SSNS_VALID ,
    NBFT_SSNS_NON_BOOTABLE_ENTRY ,
    NBFT_SSNS_USE_SECURITY_FIELD ,
    NBFT_SSNS_DHCP_ROOT_PATH_OVERRIDE ,
    NBFT_SSNS_EXTENDED_INFO_IN_USE ,
    NBFT_SSNS_SEPARATE_DISCOVERY_CTRL ,
    NBFT_SSNS_DISCOVERED_NAMESPACE ,
    NBFT_SSNS_UNAVAIL_NAMESPACE_MASK ,
    NBFT_SSNS_UNAVAIL_NAMESPACE_NOTIND ,
    NBFT_SSNS_UNAVAIL_NAMESPACE_AVAIL ,
    NBFT_SSNS_UNAVAIL_NAMESPACE_UNAVAIL

};

πŸŽ€ Constants πŸŽ€

okay so here's the whole roster, one by one, and I'm not skipping a single one because every flag here is doing its little job πŸ‘‘

  • NBFT_SSNS_VALID β€” Descriptor Valid: if it's set to 1h, then this descriptor is valid, periodt. If it's cleared to 0h, then this descriptor is not valid. And like, a host that supports NVMe-oF Boot but doesn't currently have a remote Subsystem and Namespace assigned may clear this bit to 0h. So don't come for it, it's allowed πŸ’…
  • NBFT_SSNS_NON_BOOTABLE_ENTRY β€” Non-bootable Entry Flag: set to 1h and it means this SSNS Descriptor contains a namespace of administrative purpose to the boot process, but the pre-OS may not have established connectivity to it or evaluated the contents of this Descriptor. Such namespaces may contain supplemental data that the Administrator deemed relevant as part of the pre-OS to OS hand off 🫢. That may include properties such as a UEFI device path that may not have been created for this namespace. Which means β€” and this is the important bit β€” an OS runtime may still require the contents of such a namespace to complete later stages of boot. If cleared to 0h, then this namespace did not have any special administrative intent. Nothing to see here ✨
  • NBFT_SSNS_USE_SECURITY_FIELD β€” Use Security Flag</> πŸ˜‡: if it's set to 1h, then there is a Security Profile Descriptor associated with this SSNS record and the Security Profile Descriptor Index field is valid. If cleared to 0h, then there is no Security Profile Descriptor associated with this SSNS record and the Security Profile Descriptor Index field is not valid. Everythang valid, or everythang not valid, can't be half πŸ’€
  • NBFT_SSNS_DHCP_ROOT_PATH_OVERRIDE β€” DHCP Root-Path Override Flag: set to 1h and this SSNS descriptor was populated by consuming the DHCP Root-Path on this interface. Cleared to 0h and the DHCP Root-Path was not used in populating the SSNS descriptor. It's giving "who's your daddy, DHCP?" πŸ™ˆ
  • NBFT_SSNS_EXTENDED_INFO_IN_USE β€” SSNS Extended Info In-use Flag: set to 1h and the SSNS Extended Information Offset field and the SSNS Extended Information Length field are valid. And like, this flag being set to 1h indicates that a Subsystem and Namespace Extended Information Descriptor corresponding to this descriptor is present. She's thorough, she brought receipts πŸ“‹
  • NBFT_SSNS_SEPARATE_DISCOVERY_CTRL β€” Separate Discovery Controller Flag: set to 1h means the Discovery controller associated with this volume is on a different transport address than the one specified in the Subsystem Transport Address Heap Object Reference. Cleared to 0h means the Discovery controller is the same as the Subsystem Transport Address Heap Object Reference. Same vibe, or different address, no in-between πŸ¦‹
  • NBFT_SSNS_DISCOVERED_NAMESPACE β€” Discovered Namespace Flag: set to 1h and this namespace was acquired through discovery. Cleared to 0h and this namespace was explicitly configured in the system. Found it organically vs. built it yourself, both iconic 🌈
  • NBFT_SSNS_UNAVAIL_NAMESPACE_MASK β€” Mask to get Unavailable Namespace Flag: this field indicates the availability of the namespace at a specific point in time. ⚠️ But listen β€” such use is only a hint, and its use does not guarantee the availability of that referenced namespace at any future point in time. It's a vibe check of the past, not a promise about the future, fr fr πŸ•°οΈ
  • NBFT_SSNS_UNAVAIL_NAMESPACE_NOTIND β€” Not Indicated by Driver: literally no information is provided. That's it. That's the whole flag πŸ€·β™€οΈ
  • NBFT_SSNS_UNAVAIL_NAMESPACE_AVAIL β€” Available: a referenced namespace described by this flag was previously accessible by the pre-OS driver. She used to be reachable, she's that girl ✨
  • NBFT_SSNS_UNAVAIL_NAMESPACE_UNAVAIL β€” Unavailable 😭: this namespace was administratively configured but unattempted, unavailable or inaccessible when establishing connectivity by the pre-OS driver. So like... someone set her up and then she just ghosted πŸ‘»
tiny reminder bestie πŸ’– β€” those availability flags are up there with the "hint only" caveat, so never treat NBFT_SSNS_UNAVAIL_NAMESPACE_MASK and friends as a guarantee about the future. The manpage is very clear about that and so am I 🫢

okay that's the whole page, we ate and left no crumbs πŸ‘‘ this came to you straight from the libnvme API Manual, page libnvme(2), dated July 2026, covering enum nbft_ssns_flags β€” mwah, go forth and boot responsibly πŸ’…πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from