rdma_user_mmap_io(9)

📦 version 7.3.1, in nixpkgs unstable

💖 rdma_user_mmap_io — the Kernel API Manual moment 💖

ok so bestie, welcome to the rdma_user_mmap_io(9) page 💅 this one lives in the Kernel API Manual and honestly it's giving "quietly crucial glue code" energy ✨

🌸 NAME 🌸

rdma_user_mmap_io — map IO memory into a process 🫶

⭐ SYNOPSIS ⭐

int rdma_user_mmap_io (struct ib_ucontext *ucontext , struct
       vm_area_struct *vma , unsigned long pfn , unsigned long size , pgprot_t
       prot , struct rdma_user_mmap_entry *entry );

like, six arguments, one int back, no cap 😌

🎀 ARGUMENTS 🎀

  • ucontext — the associated user context, bestie. it's literally right there in the name ✨
  • vma — the vma related to the current mmap call 🦋
  • pfn — the pfn to map. pfn, pfn, pfn 💅
  • size — the size to map 🌸
  • prot — the pgprot to use in the remap call 🔥
  • entry — the mmap_entry you got from rdma_user_mmap_entry_get, or NULL if mmap_entry isn't used by the driver 🙈 (yes, NULL is a whole valid vibe here)

👑 DESCRIPTION 👑

okay so here's the tea ☕ — drivers are supposed to call this as part of their mmap functions if they wish to send something like PCI-E BAR memory to userspace 💫 that's the whole assignment, and it ate.

Return values, listen up, because these matter:

  • -EINVAL on wrong flags or size 💀
  • -EAGAIN on failure to map 😭
  • 0 on success 🎉 slay

🌈 SEE ALSO 🌈

the way that's eleven whole references and every single one made the list 😤 no skipping, that's the rule 🧚

fr fr read the return codes before you ship — -EINVAL and -EAGAIN are not decorational 💀

and that's the page, bestie 🫶 this iconic little doc comes from ./drivers/infiniband/core, dated October 2026 — stamp it, frame it, put it on the fridge 🍓💜

📦 where this page comes from