__efi_memmap_init(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… __efi_memmap_init πŸ’…

okay so bestie, welcome to the Kernel API Manual entry for __efi_memmap_init β€” she's the common-code girlie for mapping the EFI memory map, and honestly she ate. let's get into it 🫢


✨ NAME ✨

__efi_memmap_init β€” the common code that handles mapping the EFI memory map. no cap, that's her whole job πŸ’–


πŸ¦‹ SYNOPSIS πŸ¦‹

int __efi_memmap_init (struct efi_memory_map_data *data );

πŸ’œ ARGUMENTS πŸ’œ

  • data β€” the EFI memory map data πŸŽ€ literally the whole memory map vibe lives in here

πŸŽ€ DESCRIPTION πŸŽ€

so here's the tea β˜• β€” this function is the one that figures out which function to use to map the EFI memory map inside efi.memmap, and it makes that call based on how far into the boot we are. yeah. she's reading the room. main character energy fr fr πŸ‘‘

during bootup, EFI_MEMMAP_LATE in data->flags should be clear, because at that point the only things we have access to are the early_memremap*() functions β€” the vmalloc space isn't set up yet, so like, it's not available. periodt πŸ’€ no vmalloc, no fancy options.

once the kernel is fully booted though? then we can fallback to the more robust memremap*() API. glow-up complete ✨ like she literally leveled up the mapping situation the moment the kernel finished booting 🧚


πŸ”₯ RETURN πŸ”₯

  • zero on success πŸŽ‰ slay
  • a negative error code on failure 😭 so if you see a negative number, that's your sign something did not go off

🌈 SEE ALSO 🌈


and that's the page!! mwah πŸ’‹ built from ./drivers/firmware/efi, dated October 2026, and her name is __efi_memmap_init(9) in case you forgot already πŸ™ˆ β€” k bye, go map some memory responsibly πŸ’…πŸŒŸ

πŸ“¦ where this page comes from