On Wed, 2005-09-14 at 00:57 -0400, Sergey Panov wrote: > Because set of valid LUN id represented by 8 byte combinations is not > isomorphic to the set of unsigned int values from 0 to UINT64_MAX. While The transformation we're using is an isomorphism that happens to have the important property that single level type 00b LUNs are numerically equal to the legacy uses of the lun value. > scsilun_to_int() will convert legal LUN id into some integer, the > int_to_scsilun() function will not produce legal LUN id for any > arbitrary integer lun value. No that's what I said. We limit the integer scanned luns to < 256 and use representation 00b > For example, sequential LUN scanning should be stopped at int lun = 255 > because result of converting value 256 by int_to_scsilun() will be > either illegal(best case) or equivalent to int lun = 0. It is. That's this bit of the code: @@ -965,6 +964,13 @@ static void scsi_sequential_lun_scan(str max_dev_lun = min(8U, max_dev_lun); /* + * regardless of what parameters we derived above, on no + * account scan further than SCSI_SCAN_LIMIT_LUNS + */ + if (max_dev_lun > SCSI_SCAN_LIMIT_LUNS + 1) + max_dev_lun = SCSI_SCAN_LIMIT_LUNS + 1; + > LUN id should be presented to the management layers in a way similar to > MAC addresses or FC/SAS/... WWN . E.g. the usual LUN 4 on some FC > device will be identified by something like (in 00b, or "Peripheral > device addressing"): > > WWPN = 22:00:00:0c:50:05:df:6d > LUN = 00:04:00:00:00:00:00:00 > > > Interestingly enough, the following is also LUN = 4 device, but in a > different addressing mode (01b, AKA "Logical unit addressing"): > > WWPN = 22:00:00:0c:50:05:df:6d > LUN = 40:04:00:00:00:00:00:00 Firstly, those two LUNs are actually not equivalent (according to SAM-3 section 4.9.1) because two luns are defined to be different if expressed in different representations. Secondly, The idea of using u64 is that all transports that don't use hierarchical LUNs can simply copy the number as they do today. This idea rests on the assumption that arrays responding to REPORT_LUNS on these transports always reply with type 00b. This assumption is suggested (but not mandated) in SAM. If they violate this assumption, we'll just reject all the LUNs and I'll get a bug report. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html