scsi_sequential_lun_scan(9)

📦 version 7.3.1, in nixpkgs unstable

💅 scsi_sequential_lun_scan(9) — the kernel API manual, but make it cute

okay so bestie, welcome to scsi_sequential_lun_scan(9) from the Kernel API Manual ✨ this one is a function, it lives in ./drivers/scsi, and it's literally about walking through a SCSI target's LUNs one by one until the vibes say stop. let's get into it 🫶

🌸 NAME 🌸

scsi_sequential_lun_scan — sequentially scan a SCSI target. that's it, that's the whole name, and honestly? iconic. 👑

🎀 SYNOPSIS 🎀

void scsi_sequential_lun_scan (struct Scsi_Host *shost , struct
       scsi_target *starget , blist_flags_t bflags , int scsi_level , enum
       scsi_scan_mode rescan );

that's the whole signature, no cap — five args, one void, zero drama 💅

✨ ARGUMENTS ✨

  • shost — the SCSI host pointer. like, the host of the whole party 💖
  • starget — pointer to the target structure we're gonna scan. this is our main character 🎀
  • bflags — the black/white list flag for LUN 0. yes, specifically LUN 0. mind the details bestie 🙈
  • scsi_level — which version of the standard this device adheres to. gotta know what rules we're playing by 📜
  • rescan — passed on to scsi_probe_add_lun. we don't handle it, we just hand it over 🫶

🦋 DESCRIPTION 🦋

so generally speaking 🌈 we scan from LUN 1 — because LUN 0 is assumed to already have been scanned, she's done, she's booked and busy 💅 — all the way up to some maximum lun, and we keep going until we hit a LUN that has no device attached. that's the stop condition, that's the vibe check ✨

and use the bflags to figure out any oddities 👀 like, that's what she's there for.

also, she modifies sdevscan->lun. not a read-only situation. noted. 📝

🌟 SEE ALSO 🌟

Kernel file ./drivers/scsi/scsi_scan.c — plus the whole friend group 💜:

and that's the page!! 🎀 she's from ./drivers/scsi, dated October 2026, and her whole name is scsi_sequential_lun_scan(9) — go forth and scan sequentially, bestie 💅✨

📦 where this page comes from