STRUCT FW_CDEV_EVENT_ISO_INTERRUPT_MC(9)

💅 struct fw_cdev_event_iso_interrupt_mc(9) 💅

okay so bestie, welcome to the Kernel API Manual 🎀 — this is the glow-up guide to struct fw_cdev_event_iso_interrupt_mc, and honestly? it's giving "your iso buffer chunk just finished" main character energy ✨

---

🌸 NAME 🌸

struct fw_cdev_event_iso_interrupt_mc — literally the event that says an iso buffer chunk was completed 💖

---

✨ SYNOPSIS ✨

struct fw_cdev_event_iso_interrupt_mc {
    __u64 closure;
    __u32 type;
    __u32 completed;
 };

no cap, that's the whole vibe 🫶

---

🎀 Members 🎀

• closure — go peek at fw_cdev_event_common for this one, bestie; it gets set by the FW_CDEV_CREATE_ISO_CONTEXT ioctl 💫
• type — it's FW_CDEV_EVENT_ISO_INTERRUPT_MULTICHANNEL, periodt 🌈
• completed — this is the offset into the receive buffer, and everything before this offset is valid 🧚 highkey important

---

🦋 Description 🦋

so this event shows up in multichannel contexts (that's context type FW_CDEV_ISO_CONTEXT_RECEIVE_MULTICHANNEL, iykyk) for fw_cdev_iso_packet buffer chunks that have been completely filled and that have the FW_CDEV_ISO_INTERRUPT bit set — or whenever someone explicitly asks for it with FW_CDEV_IOC_FLUSH_ISO 👑

the buffer just keeps getting filled continuously with this data, per packet:

• the 1394 iso packet header (as described at fw_cdev_event_iso_interrupt, but in little endian byte order ⭐)
• the packet payload — as many bytes as specified in the data_length field of the 1394 iso packet header — in big endian byte order 🔥
• 0...3 padding bytes as needed to align the following trailer quadlet 🎀
• the trailer quadlet, containing the reception timestamp as described at fw_cdev_event_iso_interrupt, but in little endian byte order 💜

so the per-packet size works out to data_length (rounded up to a multiple of 4) + 8, fr fr 📐 when you're processing the data, stop before a packet that would cross the completed offset — don't let it spill into your business 🙈

also, a packet near the end of a buffer chunk will typically spill over into the next queued buffer chunk. it's on the client to check for this condition, assemble a broken-up packet from its parts, and not re-queue any buffer chunks that still have as-yet-unread packet parts in them 😭 don't skip this step, bestie, it's not a drill 💀

---

👑 SEE ALSO 👑

the kernel file ./include/uapi/linux/firewire-cdev.h, plus this whole friend group 🫶:

• struct fw_cdev_event_common(9)
• struct fw_cdev_event_bus_reset(9)
• struct fw_cdev_event_response(9)
• struct fw_cdev_event_response2(9)
• struct fw_cdev_event_request(9)
• struct fw_cdev_event_request2(9)
• struct fw_cdev_event_request3(9)
• struct fw_cdev_event_iso_interrupt(9)
• struct fw_cdev_event_iso_resource(9)
• struct fw_cdev_event_phy_packet(9)
• struct fw_cdev_event_phy_packet2(9)
• union fw_cdev_event(9)
• struct fw_cdev_get_info(9)
• struct fw_cdev_send_request(9)
• struct fw_cdev_send_response(9)
• struct fw_cdev_allocate(9)
• struct fw_cdev_deallocate(9)
• struct fw_cdev_initiate_bus_reset(9)
• struct fw_cdev_add_descriptor(9)
• struct fw_cdev_remove_descriptor(9)
• struct fw_cdev_create_iso_context(9)
• struct fw_cdev_set_iso_channels(9)
• struct fw_cdev_iso_packet(9)
• struct fw_cdev_queue_iso(9)
• struct fw_cdev_start_iso(9)
• struct fw_cdev_stop_iso(9)
• struct fw_cdev_flush_iso(9)
• struct fw_cdev_get_cycle_timer(9)
• struct fw_cdev_get_cycle_timer2(9)
• struct fw_cdev_allocate_iso_resource(9)
• struct fw_cdev_send_stream_packet(9)
• struct fw_cdev_send_phy_packet(9)
• struct fw_cdev_receive_phy_packets(9)

---

and that's the whole page, bestie 💖 this cutie lives in ./include/uapi/linux, dated October 2026 — slay, ate, no crumbs ✨🎀🦋