--wzJLGUyc3ArbnUjN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

So what should we do to add 64-bit LUN support to our SCSI layer? I'm=20
looking at supporting devices that actually use them, and am soliciting=20
thoughts on what to do.

Some changes are rather simple. Places where we store LUNs now turn into=20
64-bit storage, for instance. The bigger change, though, is that we don't=
=20
want to linearly search the LUN space. So things like:

                for (lun =3D minlun; lun <=3D maxlun; lun++) {
                        /* =20
                         * See if there's a device present, and configure i=
t.
                         */=20
                        if (scsi_probe_device(sc, target, lun) =3D=3D 0)
                                break;
                        /* otherwise something says we should look further =
*/
                }

won't still work. SCSI provides the REPORT_LUNS command, so we can tell=20
what LUNs we should play with. I guess just keeping a list attached off of=
=20
the target or off of the bus would work.

The other part of the question is what to do about devices that don't=20
support REPORT_LUNS. I think some sort of fall-back to the old-style "max=
=20
LUNs" method would be best.

Thoughts?

Take care,

Bill

--wzJLGUyc3ArbnUjN
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFB3d/SWz+3JHUci9cRAr1xAJ9LxIhjqR8zJ4mKB98Uf5gFx6b6XACeO6jB
CNLsEzNxhPYpQRrz6GKi6BE=
=7AaF
-----END PGP SIGNATURE-----

--wzJLGUyc3ArbnUjN--