dma_buf_dynamic_attach(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dma_buf_dynamic_attach 💅

okay so bestie, welcome to the dma_buf_dynamic_attach(9) page from the Kernel API Manual — yes we're in kernel-land today, put your hair up 🎀

✨ NAME ✨

dma_buf_dynamic_attach — adds the device to dma_buf's attachments list 🫶

🌸 SYNOPSIS 🌸

struct dma_buf_attachment * dma_buf_dynamic_attach (struct dma_buf
*dmabuf , struct device *dev , const struct dma_buf_attach_ops
*importer_ops , void *importer_priv );

like, yes, that's a lot of asterisks, but she's serving function signature realness 💅

🦋 ARGUMENTS 🦋

  • dmabuf [in] — the buffer you're attaching the device to, literally the whole point 🍓
  • dev [in] — the device being attached, main character energy fr fr 👑
  • importer_ops [in] — the importer operations for the attachment ✨
  • importer_priv [in] — the importer's private pointer for the attachment, iykyk 🙈

💖 DESCRIPTION 💖

So what does she actually do? She returns a struct dma_buf_attachment pointer for this attachment. That's it, that's the vibe.

⚠️ but bestie listen — attachments must be cleaned up by calling dma_buf_detach. no leaving them lying around, that's not the move 😭

Optionally, this calls dma_buf_ops.attach so device-specific attach functionality can get its moment ✨

On success you get a pointer to the newly created dma_buf_attachment, or — plot twist — a negative error code wrapped into a pointer on failure 💀

And ngl, this can fail if the backing storage of dmabuf is in a place that's not accessible to dev, and it can't be moved to a more suitable place. When that happens it's indicated with the error code -EBUSY. periodt. 🔥

🌈 SEE ALSO 🌈

Kernel file ./drivers/dma-buf/dma-buf.c, plus the whole friend group:

🧚 sign-off 🧚

this lil page lives in ./drivers/dma-buf, dated October 2026, and she's filed under dma_buf_dynamic_attach(9) 💜 slay, go attach something, mwah 🫶✨

📦 where this page comes from