On 09/13/05 18:25, Patrick Mansfield wrote:
> On Tue, Sep 13, 2005 at 05:02:36PM -0400, Luben Tuikov wrote:
>
>>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).
>
>
> Not all HBA drivers implement a mapping to a SCSI transport, we have
> raid drivers and even an FC driver that has its own lun definition that
> does not fit any SAM or SCSI spec.
Us too. Especially RAID.
> I think the only HBA's today that can handle an 8 byte lun are lpfc and
> iscsi (plus new SAS ones).
>
> So, we can't have one "LUN" that fits all, and it makes no sense to call
> it a LUN when it is really a wtf.
"u64 lun" is a lot worse than "u8 LUN[8]". you can work with
the latter but the former raises questions like
"How was this translated from the "u8 LUN[8]" which I use
in the application client and in the transport?"
Etc.
Then, if your lun is 16 bits, there is no question where it is
in "u8 LUN[8]" -- SAM is _clear_ on that.
Second, as I said before a Logical Unit Number _is_ "u8 LUN[8]",
there is _no_ MSB or LSB, and there will never be. Thus, you cannot
stuff it into "u64".
Yes, we _can_ have _one_ LUN that fits all, _because_
we would copy it _as_ is from the LLDD, be it 16 bits or
32 bits or whatever, in SCSI order format: Big endian.
Again, SAM is clear on that.
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |