rproc_handle_trace(9)

📦 version 7.3.1, in nixpkgs unstable

🌸 rproc_handle_trace — Kernel API Manual energy 🎀

okay so bestie, welcome to the rproc_handle_trace(9) page 💅 this is the one that deals with a shared trace buffer resource, and honestly? it's giving "quietly doing the most important job in the room" ✨

✨ NAME ✨

rproc_handle_trace — handle a shared trace buffer resource 🫶

💫 SYNOPSIS 💫

int rproc_handle_trace (struct rproc *rproc , void *ptr , int offset ,
       int avail );

🎀 ARGUMENTS 🎀

  • rproc — the remote processor 👑 like, the whole reason we're here
  • ptr — the trace resource descriptor 📋
  • offset — offset of the resource entry 📍
  • avail — size of available data (for sanity checking the image) 🧠✨

🦋 DESCRIPTION 🦋

so when the remote processor dumps trace logs into memory, this function's whole gig is exporting it via debugfs 💖 periodt.

rn, the 'da' member of rsc should contain the device address where the remote processor is dumping the traces 📌 no cap, that's where the juice lives.

later we could also support dynamically allocating this address using the generic DMA API 🌈 but lowkey, currently there isn't a use case for that 🙈 so we're not doing it.

🌟 RETURN 🌟

0 on success, or an appropriate error code otherwise 💀 bestie either it ate or it didn't, there is no in between.

🔥 SEE ALSO 🔥

Kernel file ./drivers/remoteproc/remoteproc_core.c — go read it, iykyk 📖✨

the whole friend group, in order 🫶:

and that's the page bestie 💜 it lives in ./drivers/remoteproc, it's dated October 2026, and it will always be rproc_handle_trace(9) to me 🎀✨ slay, go unload your trace buffers responsibly 💅🌸

📦 where this page comes from