A new scan_scsis_target function based on code in scan_scsis, andparts of scan_scsis_single. Adding this function cleans up thescanning code, and removes a really ugly for loop. It would bedifficult to cleanly add REPORT LUN scanning without such a function.

Adds missing scsi_release_commandblocks() calls.

Does not set max_dev_lun out of bounds for BLIST_FORCELUN devices.

It also fixes scanning past LUN 7 for SCSI-3 devices (the patchin 2.4.17 for that fix will not apply correctly against this code).

I tested this code on a x86 system with a fastt 200 (LSI Triton,IBM 3542); this device is not very interesting, since the firmwareI have on it always gives back LUNs 0 - 31 in the REPORT LUNSresult, even when I don't have LUNs configured there.

I previously tested similar code in a 2.4.x kernel against a HitachiDF400, and an EMC Symmetrix box; the code failed when run with anEmulex adapter and driver.

I have not tested going past LUN 255, or a with the fastt configuredto appear as a sparse LUN configuration. Good test points would beto go past LUN 255, and then past LUN 2^16 (if any such devices exist,and any adapter drivers support it), and to test on a big-endian machine(past LUN 255; current linux lun is in host-order, but the SCSI 8 byteLUN is comparable to 4 short big-endian integers).

+#ifdef CONFIG_SCSI_REPORT_LUNS+/* + * max_scsi_report_luns: the maximum number of LUNS that will be+ * returned from the REPORT LUNS command. 8 times this value must+ * be allocated. In theory this could be up to an 8 byte value, but+ * in practice, the maximum number of LUNs suppored by any device+ * is about 16k.+ */+static unsigned int max_scsi_report_luns = 128;+#endif+ #ifdef MODULE

+#ifdef CONFIG_SCSI_REPORT_LUNS+MODULE_PARM(max_scsi_report_luns, "i");+MODULE_PARM_DESC(max_scsi_report_luns, "REPORT LUNS maximum number of LUNS received (should be between 1 and 16384)");+#endif+ #else