[PATCH 0/2] struct scsi_lun preparation

[PATCH 0/2] struct scsi_lun preparation

[Jeff Garzik]

A long-term, low priority project of mine is to increasingly isolate
HCIL addressing, making it easier to directly support FC/SAS-style
addressing without hacks and HCIL emulation.

The following two patches are a small part of the changes I've been
carrying for a while, in the repo
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/scsilun-2.6.git

Branches of note:

master		- vanilla linus
submit1		- patch #1; child of master
submit2		- patch #2; child of submit1
hacking		- the rest of the changes; child of submit2

THESE CHANGES ARE NOT [YET] FOR APPLICATION.  DO NOT APPLY.

Re: [PATCH 0/2] struct scsi_lun preparation

[James Bottomley]

On Mon, 2006-09-11 at 10:34 -0400, Jeff Garzik wrote:
> A long-term, low priority project of mine is to increasingly isolate
> HCIL addressing, making it easier to directly support FC/SAS-style
> addressing without hacks and HCIL emulation.

I'm not sure we want to embed an actual struct scsi_lun into the whole
of the scsi subsystem.  At the moment, given that no-one's actually
managed to find any device that goes beyond two levels, the current u32
for lun is perfectly fine.  If we're eventually forced beyond two
levels, we can consider the transition (although going to u64 does look
tempting).

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).

James

Re: [PATCH 0/2] struct scsi_lun preparation

[Jeff Garzik]

James Bottomley wrote:
> On Mon, 2006-09-11 at 10:34 -0400, Jeff Garzik wrote:
>> A long-term, low priority project of mine is to increasingly isolate
>> HCIL addressing, making it easier to directly support FC/SAS-style
>> addressing without hacks and HCIL emulation.
> 
> I'm not sure we want to embed an actual struct scsi_lun into the whole
> of the scsi subsystem.  At the moment, given that no-one's actually
> managed to find any device that goes beyond two levels, the current u32
> for lun is perfectly fine.  If we're eventually forced beyond two
> levels, we can consider the transition (although going to u64 does look
> tempting).
> 
> 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.....

	Jeff

RE: [PATCH 0/2] struct scsi_lun preparation

[Moore, Eric]

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?  

Luben?

Re: [PATCH 0/2] struct scsi_lun preparation

[Jeff Garzik]

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.

	Jeff

RE: [PATCH 0/2] struct scsi_lun preparation

[Luben Tuikov]

--- "Moore, Eric" <Eric.Moore@lsil.com> 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?  
> 
> Luben?

Hi Eric,

Yes, you are absolutely correct, LUNs as well as SAS addresses,
are indeed u8[8], for well known reasons.

    Luben

Re: [PATCH 0/2] struct scsi_lun preparation

[Luben Tuikov]

--- Jeff Garzik <jeff@garzik.org> 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.

After a while, those little things, "purely semantics" as you called
them, _accrue_ to produce the ''architecture'' of the subject matter.

As they say, "The devil is in the details."

Good luck!
       Luben

Re: [PATCH 0/2] struct scsi_lun preparation

[Douglas Gilbert]

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