Messages in this thread |  | | | Subject | Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices) | | From | Sergey Panov <> | | Date | Wed, 14 Sep 2005 00:57:24 -0400 |
| |
On Tue, 2005-09-13 at 14:36 -0600, Matthew Wilcox wrote: > > Could you explain the difference please? Why is it preferable to keep > the LUN as an array of bytes instead of a single large integer? >
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 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.
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.
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
Sergey Panov
====================================================================== Any opinions are personal and not necessarily those of my former, present, or future employers.
- 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/
|  |