On 06/27/14 09:30, Hannes Reinecke wrote: > On 06/27/2014 09:12 AM, Bart Van Assche wrote: >> On 06/25/14 15:27, Hannes Reinecke wrote: >>> scsilun_to_int() has an error which prevents it from generating >>> correct LUN numbers for 64bit values. >>> Also we should remove the misleading comment about portions of >>> the LUN being ignored; the initiator should treat the LUN as >>> an opaque value. >>> And, finally, the example given should use the correct >>> prefix (here: extended flat space addressing scheme). >> >> I'm still not enthusiast about the byte reordering by scsilun_to_int() >> for extended logical unit addressing. But I can confirm that this patch >> passed the test that failed with the previous version of the 64-bit LUN >> patch series. So if you want you can add "Tested-by: Bart van Assche >> <bvanassche@xxxxxxx>". >> > I can somewhat agree with your sentiment. > > It should be possible eg to keep the LUN in native format (as now both > have the same length) and only use scsilun_to_int() when > displaying the LUN number. > > But this needs a careful review, as occasionally the code might want to > traverse the LUN numbers by simply incrementing it, which of course > won't work anymore then. > Which was the main reason why I didn't do so in the first place. > > Now, however, the necessary bits are done, so we should have a look at > that. Let's see ... The first two bits of a SCSI LUN indicate the addressing method. Has it been considered to make the LUN encoding and decoding scheme dependent on the addressing method, e.g. keeping the current approach for multi-level simple LUNs (16 bits each) and preserving the (big endian) byte order for the extended logical unit addressing format ? For the extended logical unit addressing format the first two bits (ADDRESS METHOD) are both equal to one and the subsequent two bits indicate the LUN length. As you most likely know more details can be found in SAM-5 paragraph 4.7.7.5. Bart. -- To unsubscribe from this list: 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
