STRUCT VIORTC_MSG(9)

💅 struct viortc_msg — a lil' kernel-API-manual moment (section 9, bestie)

okay so listen. this is from the Kernel API Manual, page struct viortc_msg(9), and it's genuinely iconic because it's literally the lil' envelope a driver mails out and a device mails back. driver asks, device answers. that's the whole vibe. 🎀

---

✨ NAME ✨

struct viortc_msg — the message your driver requests and your device responds to. pen-pals but make it virtio, fr fr.

---

🦋 SYNOPSIS 🦋

struct viortc_msg {
    struct viortc_dev *viortc;
    void *req;
    void *resp;
    struct completion responded;
    refcount_t refcnt;
    unsigned int req_size;
    unsigned int resp_cap;
    unsigned int resp_actual_size;
 };

(this is the actual shape of it, copy-pasted exactly, do not come for me 💀)

---

👑 Members 👑

• viortc — the device data. like, whose message is this even. main character pointer energy.
• req — the request buffer. what you're sending out into the world 🌈
• resp — the response buffer. what comes back. the reply guy.
• responded — a struct completion that the vqueue callback signals once it's received a response. basically a "he replied!!!" notification 🫶
• refcnt — the message reference count, and it is so real about cleanup: the message and its buffers get deallocated once this hits 0. it gets decremented in two places — in the vqueue callback, and in the thread waiting on the responded completion.

ngl this next bit matters: if a message response wait function times out, the message still gets freed later — either upon late reception (that's refcnt reaching 0 in the callback) or upon device removal. no leaks, no loose ends, we love a responsible icon 💅

• req_size — size of the request, in bytes.
• resp_cap — maximum size of the response, in bytes. the cap, literally.
• resp_actual_size — the actual size of the response. not the cap. the real one. the truth. ✨

---

🌸 SEE ALSO 🌸

go read these next, bestie, they're all in the same friend group:

Kernel file ./drivers/virtio/virtio_rtc_driver.c struct viortc_vq(9), struct viortc_dev(9), viortc_class_from_dev(9), viortc_alarms_supported(9), viortc_feed_vq(9), viortc_msg_init(9), viortc_msg_release(9), viortc_do_cb(9), viortc_requestq_hdlr(9), viortc_cb_requestq(9), viortc_alarmq_hdlr(9), viortc_cb_alarmq(9), viortc_get_resp_errno(9), viortc_msg_xfer(9), VIORTC_DECLARE_MSG_HDL_ONSTACK(9), VIORTC_MSG(9), VIORTC_MSG_INIT(9), VIORTC_MSG_WRITE(9), VIORTC_MSG_READ(9), viortc_read(9), viortc_read_cross(9), viortc_cfg(9), viortc_clock_cap(9), viortc_cross_cap(9), viortc_read_alarm(9), viortc_set_alarm(9), viortc_set_alarm_enabled(9), viortc_init_rtc_class_clock(9), viortc_init_ptp_clock(9), viortc_init_clock(9), viortc_clocks_deinit(9), viortc_clocks_init(9), viortc_populate_vq(9), viortc_alloc_vq_bufs(9), viortc_init_vqs(9), viortc_probe(9), viortc_remove(9)

---

anyway that's the page!! source spot is ./drivers/virtio and the date stamp says October 2026 — so yeah, we're reading the future's manpage, lowkey obsessed, bye bestie 👋💖