libnvme(2)

💖 libnvme(2) — API Manual 💖

okay bestie, gather round, because we're diving into libnvme's man page and it's giving struct energy 🦋. This one lives in section 2 of the manual, and it's all about one very specific little guy: struct nbft_discovery. Slay.

---

✨ NAME ✨

struct nbft_discovery — the Discovery Descriptor (Figure 24). That's it, that's the name, no cap. 👑

---

🌸 SYNOPSIS 🌸

here's the whole shape of it, character for character, don't touch a thing:

struct nbft_discovery {
    __u8 structure_id;
    __u8 flags;
    __u8 index;
    __u8 hfi_index;
    __u8 sec_index;
    __u8 reserved1;
    struct nbft_heap_obj discovery_ctrl_addr_obj;
    struct nbft_heap_obj discovery_ctrl_nqn_obj;
    __u8 reserved2[14];
 };

look at that struct. so tidy. so structured. main character energy fr fr. 💅

---

🎀 Members 🎀

okay so let's go field by field, because every single one of these matters and I would never skip one. obsessed with thoroughness. ✨

• structure_id — Structure ID, bb. This field shall be set to 6h (aka the Discovery Descriptor, aka #NBFT_DESC_DISCOVERY). It's like a little name tag so everyone knows what kind of record this is. 🏷️
• flags — the Discovery Descriptor Flags. Wanna know what's in there? Go look at enum nbft_discovery_flags, because that's where the tea lives. 🍵
• index — Discovery Descriptor Index. This tells you which number this Discovery Descriptor is in the Discovery Descriptor List. Like a seat number at the function. 💺
• hfi_index — HFI Descriptor Index. This holds the value of the HFI Descriptor Index field of the HFI Descriptor that's associated with this Discovery Descriptor. And like — important detail — if multiple HFIs share a common Discovery controller, then there shall be multiple Discovery Descriptor entries, one per HFI. Not one entry doing overtime. one each. periodt. 👯
• sec_index — Security Profile Descriptor Index. This one's the value of the Security Profile Descriptor Index field of the Security Descriptor associated with this Discovery Descriptor. Security bestie stays linked. 🔐
• reserved1 — Reserved. It's just… sitting there. Respectfully. 🙈
• discovery_ctrl_addr_obj — Discovery Controller Address Heap Object Reference. This field tells you the location and size of a heap object holding a URI, and that URI indicates an NVMe Discovery controller associated with this Discovery Descriptor. If this field is cleared to 0h, then no URI is specified. Empty. Void. ghosted. 😭
• discovery_ctrl_nqn_obj — Discovery Controller NQN Heap Object Reference. If this is set to a non-zero value, it indicates the location and size of a heap object containing an NVMe Discovery controller NQN. And if the NVMe Discovery controller that this record references requires secure authentication with a well known Subsystem NQN, then this field indicates the unique NQN for that NVMe Discovery controller. This record is involved formatted as an NQN string. If this field is cleared to 0h, then this field is reserved and the OS shall use the well known discovery NQN for this record. so basically: zero = the OS falls back to the well known one. noted. 🫶
• reserved2 — Reserved. Again. Also just vibing. 💀

---

quick vibe check bestie: reserved1 and reserved2 are reserved, okay? don't go reading meaning into them, they're not for you. and that 0h clearing behavior on the two heap objects? that's load-bearing. remember it. 🌈

---

and that's the whole page!! struct nbft_discovery, dissected, every field accounted for, nothing skipped, we ate and left no crumbs 🍓✨

this came to you from the struct nbft_discovery corner of libnvme(2), dated July 2026 💜 — take care of your descriptors and they'll take care of you. bye bestie!! 🌸🦋💖