Subject: Re: 64-bit LUN support
To: Eduardo Horvath <eeh@NetBSD.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 01/07/2005 11:29:39
--gr/z0/N6AeWAPJVB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 07, 2005 at 06:45:31PM +0000, Eduardo Horvath wrote:
> On Fri, Jan 07, 2005 at 10:34:15AM -0800, Bill Studenmund wrote:
>=20
> > 64-bit LUNs are hierarchical. They consist of 4 16-bit values. "Normal"=
=20
>=20
> Don't count on it.  LUN format is application dependent.  There are
> at least two example implementations in the standards documetnation
> which use the bits quite differently.  And I'm aware of some others.

Well, the mapping I describe of changing LUNs at passthrough is right out=
=20
of SAM2 & SAM3. And its main point is to explain why we'd want 64-bit=20
LUNs.

> Unless you can be sure that a device uses a particular LUN format
> it's best to consider them to be opaque cookies.  LUN values can
> change as a device changes state or is reconfigured (ISTR there's
> a unit attention condition associated w/that).

I agree we should consider them opaque.=20

Take care,

Bill

--gr/z0/N6AeWAPJVB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFB3uMjWz+3JHUci9cRAmo2AJ9chytTJkJLA4lewnWOmmYQ9Y2RZgCeKVG8
KcMw8nux7kYFlKmEpwjv+20=
=sR+O
-----END PGP SIGNATURE-----

--gr/z0/N6AeWAPJVB--