libnvme(9)

💖 libnvme(9) — API Manual, bestie edition 💖

Okay so real talk: this is a page straight out of the libnvme API Manual, and it's about one little struct that's honestly kind of the main character of AEM messages. Buckle up 🎀

---

✨ NAME ✨

struct nvme_mi_aem_msg — the AEM Message definition. That's it, that's the whole vibe. 💅

---

🌸 SYNOPSIS 🌸

Here's the struct in all its glory — copy it exactly, no cap:

struct nvme_mi_aem_msg {
    struct nvme_mi_msg_hdr hdr;
    struct nvme_mi_aem_occ_list_hdr occ_list_hdr;
 };

---

🫶 MEMBERS 🫶

• hdr — the general response message header. It's giving "hello, I'm the header," very introductory.
• occ_list_hdr — the ae occurrence list header. This one's the lineup announcement for everything that follows, iykyk.

---

🦋 DESCRIPTION 🦋

Every ae message starts with one of these bad boys. Literally every single one — it's the opening act. 🌟

The occ_list_hdr defines the info about how many ae occ data entries are included. Then each entry is defined by the nvme_mi_aem_occ_data structure, and those come right after the occ_list_hdr.

Here's the spicy part 🔥 — each nvme_mi_aem_occ_data structure has a fixed length header but a variable length payload, because of occurrence-specific and vendor-specific info. It's flexible like that. 💃

So for that exact reason: do not index the nvme_mi_aem_occ_data structures by array or by fixed offset. Nope. Don't do it. That's the one thing you cannot do here, bestie. 😭

---

And that's the whole page, periodt. 🌈

Cute little sign-off: this gem dropped in October 2026, it's all about struct nvme_mi_aem_msg, and the manpage fam is libnvme(9). Slay, go forth and parse those messages responsibly. 👑💜