Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 09/14/05 14:43, James Bottomley wrote:
> 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.

I was actually going to reply to this email and write something
sensible, but on second thought I see that it would be 
a _complete_ waste of time, effort and keystrokes.

  "If they violate this assumption, we'll just reject all the LUNs"
and
  "I'll get a bug report"
tops it all off.

	Luben


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/