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

[James Bottomley <James.Bottomley@SteelEye.com>]

On Mon, 2005-09-12 at 09:45 -0700, Patrick Mansfield wrote:
> On Mon, Sep 12, 2005 at 09:57:21AM -0500, James Bottomley wrote:
> > be free to increase it if necessary.  Note: you do actually need either
> > an array with more than two levels of nesting actually to need the
> > increase and no-one actually seems to have one of these yet.
> 
> That is not correct, I posted before on this, the address method is in the
> high bits of the 8 byte LUN and tells how to "interpret" the LUN value.
> You can't convert from an int to 8 byte LUN (without any other
> information) and set these bits. See SAM-4 in (or near) section 4.9.7.
> 
> So some storage devices that want to use addressing methods other than 00b
> don't because we do not have 8 byte LUN support in linux, and then we have
> other problems because of this.

Well, as long as we represent the u32 (or u64) as

scsilun[1] | (scsilun[0] << 8) | (scsilun[3] << 16) | (scsilun[2] << 24)

I think we cover all 2 level lun bases, don't we (obviously we ignore
levels 3 and 4 [and 6 and 8 byte extended luns])?

That representation works transparently for type 00b which is what SPI
and other legacy expects, since our lun variable is equal to the actual
numeric lun.  Although SAM allows type 01b for arrays with < 256 LUNs it
does strongly suggest you use type 00b which hopefully will cover us for
a while longer...

fc already uses int_to_scsilun and 8 byte LUN addressing, so it will
work even in the 01b case (the numbers that the mid-layer prints will
look odd, but at least the driver will work).

James


-
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/