libnvme_mi_...t_next_event(9)

📦 version 3.2, in arch rolling

💅 libnvme_mi_aem_get_next_event(9) — from the libnvme API manual, bestie 🎀

okay so bestie, welcome to the glow-up of libnvme_mi_aem_get_next_event(9) ✨ like yes the title is a whole mouthful but she's iconic and we're gonna get through it together, i promise 🫶

🌸 NAME 🌸

libnvme_mi_aem_get_next_event — literally just "get details for the next event to parse" 💫 that's the whole vibe.

✨ SYNOPSIS ✨

struct libnvme_mi_event * libnvme_mi_aem_get_next_event (struct libnvme_mi_ep *ep );

there she is. one function, one arg, no drama 💅

🦋 ARGUMENTS 🦋

  • ep — the endpoint that's holding the event, aka the main character of this call 👑

💖 DESCRIPTION 💖

so picture it: you're inside an aem_handler (iykyk), and you call this little icon, and the struct pointer that comes back hands you all the deets on the event info 🔥

she'll return NULL when the end of parsing has occurred — like okay periodt, we're done here 💀

⚠️ real talk though: spec_info and vend_spec_info must be copied if you want them to persist, because they will not be valid after handler_next_action has returned. not me warning you twice, it's giving "copy it or lose it" 😭🙈

⭐ RETURN ⭐

pointer to the next libnvme_mi_event, or NULL if this is the last one 🌈 (yes that's the vibe check passing or failing, no in between).

and that's the whole page, bestie 🍓 go forth and parse those events, no cap 💜

signed with love: this was the libnvme API manual, version libnvme_mi_aem_get_next_elibnvme_mi_...t_next_event(9) (yes girl that footer said what it said 🙈), dated October 2026 🎀

📦 where this page comes from