drm_gem_dmabuf_export(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… drm_gem_dmabuf_export(9) β€” like, the Kernel API Manual page, bestie

okay so this is drm_gem_dmabuf_export, straight out of the Kernel API Manual, and it's lowkey the glue that makes GEM buffers escape into dmabuf land ✨


✨ NAME ✨

drm_gem_dmabuf_export β€” the &dma_buf export implementation for GEM, no cap πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

struct dma_buf * drm_gem_dmabuf_export (struct drm_device *dev , struct
dma_buf_export_info *exp_info );

like, that's the whole signature. she's short, she's iconic, she does exactly one thing πŸ‘‘


🌸 ARGUMENTS 🌸

  • dev β€” the parent device for the exported dmabuf 🫢 like, the actual grown-up device this thing belongs to.
  • exp_info β€” the export information used by dma_buf_export πŸ’– everything else she needs to know lives in here.

πŸ”₯ DESCRIPTION πŸ”₯

okay so picture this: this function wraps dma_buf_export for generic GEM drivers that are using drm_gem_dmabuf_release. it's giving "convenience wrapper, but make it safe" πŸ’…

and it's not just calling dma_buf_export and dipping β€” nope, not her. in addition to calling dma_buf_export, we take a reference to the drm_device and to the exported drm_gem_object (which is stored in dma_buf_export_info.priv). those refs get released by drm_gem_dmabuf_release later, so the lifetime rules actually hold together. main character energy for real ✨

and the return value? returns the new dmabuf. slay πŸŽ€


πŸ‘‘ SEE ALSO πŸ‘‘

bestie go read these, i'm literally begging:


okay that's the page!! πŸ’œ it lives under ./drivers/gpu/drm, it's dated October 2026, and it is absolutely still drm_gem_dmabuf_export(9) β€” mwah, go export some buffers responsibly πŸ§šβ€β™€οΈπŸ’–

πŸ“¦ where this page comes from