scan_dirty_idx_cb(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… scan_dirty_idx_cb(9) β€” bestie edition πŸŽ€

Okay so real quick before we dive in: this is a page from the Kernel API Manual, and it's all about scan_dirty_idx_cb β€” a callback that the scan for a dirty index LEB uses. Yes, that's the whole vibe. Let's go ✨


🌸 NAME 🌸

scan_dirty_idx_cb β€” literally just the callback that the scan for a dirty index LEB uses. That's it, that's the function 🫢


✨ SYNOPSIS ✨

int scan_dirty_idx_cb (struct ubifs_info *c , const struct ubifs_lprops
*lprops , int in_tree , void *arg );

She takes four arguments and returns an int. Iconic behavior honestly πŸ‘‘


πŸŽ€ ARGUMENTS πŸŽ€

  • c β€” the UBIFS file-system description object. The whole fs, in object form πŸ’–
  • lprops β€” the LEB properties to scan. Like, the actual props being looked at.
  • in_tree β€” whether the LEB properties are in main memory. Yes/no energy 🌈
  • arg β€” information passed to and from the caller of the scan. Note that it goes both ways β€” it's giving main character bidirectional communication πŸ’…

πŸ’œ DESCRIPTION πŸ’œ

So what does this function do? It returns a code, and that code tells you which of three things is happening:

  1. Whether the scan should continue β€” LPT_SCAN_CONTINUE ✨
  2. Whether the LEB properties should be added to the tree in main memory β€” LPT_SCAN_ADD 🌸
  3. Whether the scan should stop β€” LPT_SCAN_STOP πŸ’€

Three constants, three moods. Pick your fighter. No cap, that's the entire description πŸ™ˆ


πŸ¦‹ SEE ALSO πŸ¦‹

All of these, bestie, in the exact order they appear β€” I'm not skipping a single one 🀞


🫢 That's the whole page, you ate that. Now go read find.c and slay πŸ’…

Sign-off time, bestie 🌟 this masterpiece lives at ./fs/ubifs, dated October 2026, and she goes by scan_dirty_idx_cb(9) β€” remember the name, periodt πŸ‘‘

πŸ“¦ where this page comes from