STRUCT FW_CDEV_EVENT_REQUEST3(9)

💅 struct fw_cdev_event_request3(9) 💅

ok so this is from the Kernel API Manual, section 9 — and bestie, it's giving "incoming firewire request dropped into your lap and now you have to deal with it." Let's get into it ✨

---

🎀 NAME 🎀

struct fw_cdev_event_request3 — literally the event that gets sent when a request comes in to an address region. That's it. That's the whole vibe. 🦋

---

✨ SYNOPSIS ✨

struct fw_cdev_event_request3 {
    __u64 closure;
    __u32 type;
    __u32 tcode;
    __u64 offset;
    __u32 source_node_id;
    __u32 destination_node_id;
    __u32 card;
    __u32 generation;
    __u32 handle;
    __u32 length;
    __u32 tstamp;
    __u32 padding;
    __u32 data[];
};

look at her. all those fields. main character struct fr fr 💜

---

🌸 Members 🌸

• closure — look at fw_cdev_event_common for the deets; this one gets set by the FW_CDEV_IOC_ALLOCATE ioctl 🫶
• type — also see fw_cdev_event_common; it is always FW_CDEV_EVENT_REQUEST2 (yes bestie, in request3. don't ask, it's iconic) 👑
• tcode — the transaction code of the request that just rolled in 💫
• offset — where in the 48-bit per-node address space we're at, no cap 📍
• source_node_id — the sender's node ID, i.e. who sent it 💌
• destination_node_id — the destination node ID, i.e. who it's for 🎯
• card — the index of the card the request came from 🃏
• generation — the bus generation where this request is actually valid ⏳
• handle — a reference to the kernel-side pending request. hold onto this one, you'll need it 🌟
• length — data length, meaning the request's payload size in bytes 📏
• tstamp — the time stamp of the isochronous cycle when the request arrived. clocked it ⏰
• padding — filler bytes keeping the struct size a multiple of 8 across architectures, because the System V ABI for i386 uses 4 byte alignment for 8 byte object types. it's giving "structural support" 💀
• data — the incoming data, if there is any 🍓

---

🔥 Description 🔥

okay so picture this: the stack gets an incoming request to an address region that was registered with the FW_CDEV_IOC_ALLOCATE ioctl, and this event is what gets sent. periodt. 🎀

the request is guaranteed to be completely contained in the specified region — love that for you. your job, as userspace, is to send the response back via the FW_CDEV_IOC_SEND_RESPONSE ioctl, using the same handle. don't lose the handle, bestie 😭

for requests that carry data (write requests and lock requests), the payload data follows immediately and you can get at it through the data field. slay 🦋

unlike fw_cdev_event_request, the tcode of lock requests is one of the firewire-core specific range TCODE_LOCK_MASK_SWAP...TCODE_LOCK_VENDOR_DEPENDENT — meaning it encodes the extended transaction code. iykyk 💅

card may differ from fw_cdev_get_info.card, and that's because requests get received from all the cards of the Linux host. source_node_id, destination_node_id, and generation all pertain to that card. so the destination node ID and the bus generation may differ from the corresponding fields of the last fw_cdev_event_bus_reset. it's not a glitch, it's a feature 🌈

destination_node_id may also differ from the current node ID — either because of a non-local bus ID part, or in the case of a broadcast write request. side note bestie: a client must call an FW_CDEV_IOC_SEND_RESPONSE ioctl even in the case of a broadcast write request. the kernel will then release the kernel-side pending request but will not actually send a response packet. so like… you still have to call it, it just doesn't do the reply part 🙈

in the case of a write request to FCP_REQUEST or FCP_RESPONSE, the kernel already sent a write response immediately after the request was received. in this case the client must still call an FW_CDEV_IOC_SEND_RESPONSE ioctl to release the kernel-side pending request, though another response won't be sent. same energy: call it anyway, it's about the release not the reply 💀

⭐ important bestie: if the client subsequently needs to initiate requests to the sender node of an fw_cdev_event_request3, it needs to use a device file with a matching card index, node ID, and generation for outbound requests. match the vibes or it won't work 🫶

tstamp is the isochronous cycle at which the request arrived. it's a 16 bit integer value — the higher 3 bits express three low order bits of the second field in the format of the CYCLE_TIME register, and the rest of the 13 bits express the cycle field. math but make it cute ✨

---

⭐ SEE ALSO ⭐

Kernel file ./include/uapi/linux/firewire-cdev.h, plus the whole squad:

• 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_iso_interrupt(9)
• struct fw_cdev_event_iso_interrupt_mc(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 one lives in ./include/uapi/linux and it's dated October 2026 — so like, future icon behavior 👑 mwah, go release those pending requests, ily 🫶💜