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

[Hannes Reinecke <hare@suse.de>]

On 03/26/2013 07: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)?
>
Yes, you can.

The idea here is to let 'max_luns' control this behaviour; 
'max_luns' is the highest LUN number the host can support.
So for 16-bit LUN you would set max_luns to '0xFFFF', and for 32-bit
LUN addresses you would be setting max_luns to '0xFFFFFFFF'.

However, since you mention it, maybe I should add a 'scsilun_to_u32'
conversion routine, as this is requested in several places.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html