add_fastmap(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… add_fastmap β€” kernel API manual, but make it make sense

okay so bestie, this one lives in the add_fastmap(9) section of the Kernel API Manual, and it's genuinely not that deep once you see it. let me put you on. 🫢


✨ NAME ✨

add_fastmap β€” adds a Fastmap related physical eraseblock. that's it. that's the whole vibe. one job, does it, slays. πŸ’…


✨ SYNOPSIS ✨

int add_fastmap (struct ubi_attach_info *ai , int pnum , struct
ubi_vid_hdr *vid_hdr , int ec );

like, four things go in, an int comes out. classic. πŸŽ€


✨ ARGUMENTS ✨

  • ai β€” the attaching information. literally the whole context of the attach we're doing rn. main character energy. πŸ‘‘
  • pnum β€” the physical eraseblock number that the VID header came from. we're keeping receipts on where it came from fr fr.
  • vid_hdr β€” the volume identifier header. yes queen, the VID header. πŸ’œ
  • ec β€” the erase counter of the physical eraseblock. gotta know how cooked it is. πŸ”₯

✨ DESCRIPTION ✨

so what this function does is: it allocates a struct ubi_ainf_peb object for a Fastmap physical eraseblock pnum, and then it adds it to the fastmap list. periodt. 🌸

and which blocks end up in that list? honestly both kinds, bestie: Fastmap super blocks and Fastmap data blocks β€” and they can come from either the most recent Fastmap we're attaching from, or from old Fastmaps. and those old ones? yeah, they're gonna get erased. πŸ’€ not us being dramatic, that's just what happens to them.


🌈 SEE ALSO 🌈

the whole friend group, all tagged (9), all from the Kernel file ./drivers/mtd/ubi/attach.c:

no cap, if you're deep in UBI attach code, you're gonna meet every single one of these. it's giving family reunion. πŸ™ˆ

and that's the page, bestie β€” brought to you by ./drivers/mtd/ubi, stamped October 2026, living under the Kernel API Manual umbrella, filed under add_fastmap(9). go forth and attach. πŸ¦‹βœ¨

πŸ“¦ where this page comes from