In message <20050107010314.GB12668@netbsd.org>,
Bill Studenmund writes:
>
>--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? 

[...]
>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.

Hi Bill,

Its been years time since I checked the T10/T11 drafts, but as best I
recall, there's some SCSI level (SCSI-3? The last ANSI level?)  where
any device claiming that level is required(?) to implement
REPORT_LUNS.

I've also seen devices just below that level which just won't talk
happily to an initiator unless the initiator sends them a REPORT_LUNS.
(The Compaq RA4000 RAID array was infamous for that. IIRC, the Linux
driver for the recommended Compaq/Aglient controller sent a REPORT
LUNs from inside the driver, then remapped the native LUNs to 8-bit
LUNS for upper layers; or something equally distaseful.)

So (though it may well be what you planned) I suggest something like:

  1. Sending REPORT LUNS to any devices which report themselves as SCSI-3
  2. Add a quirk table for SCSI-2 devices which reallyh want a REPORT_LUNS;
  3. Fall back to the linear probe for all other devices not covered by 1 and 2,
     which don't have the quirk that they're a single-LUn device that
     incorrectly reports itself present on all LUNs.

Havent thought about the storage issues, tho.