memblock_add_range(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay so welcome to the Kernel API Manual, bestie β€” this is the page for memblock_add_range, and it does exactly what it says on the tin: add new memblock region. iconic behavior, honestly.


✨ SYNOPSIS ✨

       int __init_memblock memblock_add_range (struct memblock_type *type ,
       phys_addr_t base , phys_addr_t size , int nid , enum memblock_flags
       flags );

🌸 ARGUMENTS 🌸

  • type β€” the memblock type to add new region into. like, which vibes bucket are we putting this in?
  • base β€” base address of the new region. the starting point, the main character coordinate.
  • size β€” size of the new region. how much space it's taking up, no cap.
  • nid β€” nid of the new region. literally just the nid, bestie.
  • flags β€” flags of the new region. the little extra details, iykyk.

πŸ¦‹ DESCRIPTION πŸ¦‹

Add new memblock region [base, base + size) into type. the way that range is giving [base, base + size) is so clean.

The new region is allowed to overlap with existing ones β€” overlaps don't affect already existing regions. so yes, overlap is allowed, but it's not out here rewriting the existing regions. periodt.

After the addition, type is guaranteed to be minimal (all neighbouring compatible regions are merged). that's the glow-up: all neighbouring compatible regions get merged, and type stays minimal. obsessed.


πŸ”₯ RETURN πŸ”₯

0 on success, -errno on failure. that's it. that's the return vibe check.


πŸ’œ SEE ALSO πŸ’œ

the whole squad, fr fr:


cute sign-off time: source/version is ./mm, dated October 2026, and the page is memblock_add_range(9) β€” bye bestie, go slay those memblock regions πŸ’…βœ¨

πŸ“¦ where this page comes from