Re: [PATCH 0/2] struct scsi_lun preparation

[Douglas Gilbert <dougg@torque.net>]

Jeff Garzik wrote:
> Moore, Eric wrote:
>> On Monday, September 11, 2006 1:56 PM, Jeff Garzik wrote:
>>>> A pretty print for the current u32 would be very useful though for
>>>> transports dealing with non single level luns (or address 
>>> methods other
>>>> than zero).
>>> A better subject line would have been "HCIL isolation" I suppose.  I
>>> would like to see increased usage of the accessors already present in
>>> include/scsi/scsi_device.h, which would ease the transition from
>>> hardcoded HCIL struct members to a more flexible addressing method.
>>>
>>> Though, FWIW, for LUNs I would certainly like to see u64 rather than
>>> u32.....
>>>
>>
>> shouldn't luns be defined as:
>> u8 lun[8] instead of u64?  
> 
> Please, not that argument again :)
> 
> It's purely semantics, the same storage is used, and only very rarely
> are the contents actually examined in either case.

James Bottomley asked Alberto Cammozzo yesterday
to see the output of 'sg_luns -v' so it ain't
that rare.

http://www.t10.org/ftp/t10/drafts/sam4/sam4r07.pdf
section 4.6.2 discusses a 64 bit lun's
"representation format". Assuming a 'u8 lun[8]'
representation fetched directly from a REPORT
LUNS response, then the first two bytes (i.e.
lun[0] and lun[1]) are most often of interest.
SCSI-2 (3 bit luns) map to lun[1] (with lun[0]=0),
eight bit luns also map to lun[1], 16 bit luns
map to lun[0] (msb) and lun[1] (lsb).

For more background, Rob Elliott wrote a document
on the subject (06-003r1 at www.t10.org).

Doug Gilbert