Re: [PATCH] scsi: Allow 64-bit LUNs during report lun scan

[Jeremy Linton <jlinton@tributary.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/2013 9:38 PM, James Bottomley wrote:
> Yes.  The two functions are simple transforms ensuring that we can pack up
> to two levels of luns into a u32 whatever address method is used.  At the
> time it was done, no array or other extant system went beyond this.
> 
> At the end of the day, a LUN is just a handle, so even if we go to 64 bits
> we're still going to be packing the address method into the logical unit
> "number".

	Ok, I will buy that (probably violates SAM5, 4.7.1, but no big deal), two
points.

	First this requires basically every adapter capable of recieving address
method!=0 LUNs to set the 64-bit capable flag that is included in this patch.
Otherwise the "scsi: %s lun%d has a LUN larger than allowed by the host
adapter\n" path fires even for a small number of luns because the address
method bit creates a "lun" > max_luns in all cases.



	Second, its possible with address method 11b, that none of the devices are
actually visible even with this patch, as a device that chooses to use address
method=11b and one of the >16 bit addressing methods gets its LSB truncated by
the 32-bit return from scsilun_to_int(). Not that I have see one of those, no
one needs that many LUNs <chuckle>. So, the flag in this patch is somewhat
misnamed as it doesn't really support 64-bit luns. To stick to the existing
method scsilun_to_int needs to be u64.


	BTW: Tiny syntax cleanup, scsilun_to_int() should have a return type of
unsigned.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHSa0AAoJEL5i86xrzcy7K6oH/RBnWrpDJGt+mcvR8of6BM6y
nwtokc/GCas/RFcn1rxvayicKcqAgYGeE7PRoECvIiDoSNFacNGCvf3XQye4tF2y
IMfGZhKlndJWKUppv5ELgyzpEbh49U3XK/Vq7O2B6pB46O6Iiqz1PUWK+yZF757B
O1Q+w49FUSbq3AsPxYh4CeHj7+L+6o6mAILzl8lTgGGRkhQFr15jR1K29AUhMyyM
xCTeWw++N9Iu5ENjIdiBk0E5bQZujKBBrSpuqWnyqPzhGX74AYexkOkEiXGlEBO7
Vr31C6TBVdpOvVdXlGoR/+ZcUxju1Q9ozmdW0QEzGMvNDbax3sS0/7wSZy9bKb4=
=j5FP
-----END PGP SIGNATURE-----