nvme_mi_aem_enable(9)

✨ nvme_mi_aem_enable ✨

okay bestie, welcome to the libnvme API manual, section 9 — and today's main character is nvme_mi_aem_enable, aka the girl whose whole job is turning on Asynchronous Events (AEs) on an endpoint 💅

---

🌸 NAME 🌸

nvme_mi_aem_enable — Enable AE on the provided endpoint

---

🦋 SYNOPSIS 🦋

int nvme_mi_aem_enable (nvme_mi_ep_t ep , struct nvme_mi_aem_config
*config , void *userdata );

---

🎀 ARGUMENTS 🎀

• ep — the Endpoint you wanna enable AEs on 🫶
• config — your AE configuration, which includes which events are enabled and the callback function. it's giving "here's the whole vibe, now go off" ✨
• userdata — an application-provided context pointer for the callback function. your little backpack of stuff you wanna carry along 🎒

---

💖 DESCRIPTION 💖

so like, you call this function to enable AE on the endpoint. no cap.

Once that's happening, the endpoint will hand over the initial state (if there is any) of the enabled AEs, and your application can parse all of that through the aem_handler fn pointer inside callbacks. and where do you get those? bestie, you grab them in the callback by calling nvme_mi_aem_get_next_event. simple as 🧚

Your application should poll the fd — and you can get that fd from nvme_mi_aem_get_fd — and then call nvme_mi_aem_process when the poll says data is available. that's the whole loop, iykyk 🔥

A call to nvme_mi_aem_process will grab the AEM data and call the aem_handler fn pointer. at that exact point, your application can call nvme_mi_aem_get_next_event to get the info for each triggered event. one event at a time, iconic behavior 👑

---

⭐ RETURN ⭐

0 is a success, nonzero is an error — and errno may be read for further details. so if it's nonzero, go read errno, she's trying to tell you something 😭

---

and that's the whole page, bestie 💜 this one came from the libnvme API manual, dated August 2026 — nvme_mi_aem_enable(9), periodt. 🎀