bt_for_each(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– bt_for_each β€” like, the kernel manual page for it ✨

bestie, this is bt_for_each from the Kernel API Manual, and it is literally about iterating over the requests associated with a hardware queue 🌸 it's giving "walk the tags, one rq at a time" energy and honestly? iconic.


✨ NAME ✨

bt_for_each β€” iterate over the requests associated with a hardware queue πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

void bt_for_each (struct blk_mq_hw_ctx *hctx , struct request_queue *q ,
struct sbitmap_queue *bt , busy_tag_iter_fn *fn , void *data , bool
reserved );

okay so it takes six things and returns void, no cap πŸ’…


πŸ‘‘ ARGUMENTS πŸ‘‘

  • hctx β€” the hardware queue you want to examine. that's the one, bestie πŸ”
  • q β€” the request queue that hctx is associated with, aka hctx->queue. yep, that exact member 🫢
  • bt β€” the sbitmap to examine. this is either the breserved_tags member or the bitmap_tags member of struct blk_mq_tags β€” pick your fighter, but only those two 🌈
  • fn β€” a pointer to the function that gets called for each request associated with hctx that has been assigned a driver tag. it's called like this:
fn(rq, data)

where rq is a pointer to a request. return true to keep iterating tags; return false to stop πŸ”₯ like, that's the whole vibe check right there β€” false means you're done, periodt.

  • data β€” gets passed as the second argument to fn. it's your little payload, carrying whatever you need πŸŽ€
  • reserved β€” tells you whether bt is the breserved_tags member or the bitmap_tags member of struct blk_mq_tags ⭐ (yes it's the same either/or situation from bt, it's just being confirmed here, k?)

🌸 SEE ALSO 🌸

go read those too, they're all in the same friend group fr fr πŸ’œ


mwah πŸ’‹ this page lives in ./block, the date on it is October 2026, and it's the bt_for_each(9) page from the Kernel API Manual β€” that's the whole sign-off bestie, go iterate some tags πŸ§šβ€β™€οΈβœ¨

πŸ“¦ where this page comes from