Re: [PATCH 0/4] scsi: 64-bit LUN support

[Douglas Gilbert <dgilbert@interlog.com>]

On 13-03-26 02:00 PM, Chad Dupuis wrote:
>
>
> On Tue, 19 Feb 2013, Hannes Reinecke wrote:
>
>> This patchset updates the SCSI midlayer to use 64-bit LUNs internally.
>> It eliminates the need to limit the number of LUNs artificially to
>> avoid aliasing issues; the SCSI midlayer can now accept any LUN presented
>> to it.
>>
>> The LLDD specific settings for 'max_lun' have been left untouched;
>> it should be raised to '~0' if the HBA supports 64-bit LUNs internally.
>> However, it is up to the driver maintainer to raise that limit.
>>
>> Hannes Reinecke (4):
>>  scsi_scan: Fixup scsilun_to_int()
>>  scsi: use 64-bit LUNs
>>  scsi: use 64-bit value for 'max_luns'
>>  scsi: Remove CONFIG_SCSI_MULTI_LUN
>>
>
> Hannes,
>
> As we've reviewed these patches internally, the one question that keeps
> coming up is how do we handle hardware that cannot handle a 64-bit LUN
> address? For example, some of our older 2G/bps hardware can only handle a
> 16-bit LUN address.  Currently we convert the u32 value to u16.  Do we do
> the same for the 64-bit conversion? Can a way be devised to "opt-out" of
> receiving a 64-bit address in the first place (IIRC this was an option in
> the v1 patch set)?

Chad,
Perhaps I'm missing something. Given a t10_LUN and linux32_LUN
and the proposed linux64_LUN then the traditional 16 bit LUN
value (flat space addressing ?) would be either:
     (t10_LUN[0] << 8) | t10_LUN[1]
or
     linux32_LUN & 0xffff
or
     linux64_LUN & 0xffff


Doug Gilbert