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

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 09/13/05 16:36, Matthew Wilcox wrote:
> On Tue, Sep 13, 2005 at 04:23:42PM -0400, Luben Tuikov wrote:
> 
>>A SCSI LUN is not "u64 lun", it has never been and it will
>>never be.
>>
>>A SCSI LUN is "u8 LUN[8]" -- it is this from the Application
>>Layer down to the _transport layer_ (if you cared to look at
>>_any_ LL transport).
> 
> 
> 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?

A LUN is at the same concept level as a CDB.

You can see this by reading SAM or looking at the definition
of _any_ transport frame of _any_ transport (close your eyes and
pick one).

What you will see is that there is no "MSB" or "LSB" for
things like CDB and LUN fields.

SAM is very explicit on this, especially for LUN the language
used is very affirmative.

>>(It is also capitalized since it is an abbreviation.)
> 
> 
> Well, we have two conflicting standards to follow here.  That of English
> which insists that abbreviations be capitalised, and that of the kernel
> which requires that all-caps identifiers be macros rather than structure
> members.  We have to violate one.

I've never seen the symbols "lun".  In any spec
"Logical Unit Number" and "LOGICAL UNIT NUMBER" have always
been abbreviated "LUN".

As to code, it is completely clear which is which.  If you take
a look at the SAS code you know immediately what 
"task->ssp_task.LUN" is.  It is what you'd see in a spec, in the
transport frame, the "LUN", "u8 LUN[8]" field.

After a while, this becomes second nature to you.

	Luben