On Fri, Jan 07, 2005 at 08:00:22AM -0500, der Mouse wrote:
> > If there are a lot of [LUNs] we may have issues with the
> > chan_periphtab[] has table.  Right now it's 16.  But if a periph can
> > have hunderd of LUNs (and I guess some have, otherwise what would be
> > the purpose of 64bit LUN ?)
> 
> I don't really know, but I have some guesses.
> 
> Clearly no device needs enough LUNs, in the original sense of a
> per-target unit namespace, to need 64 bits of count.  I have trouble
> imagining any that would overrun 16 bits, and few that would overrun 8.
> These LUNs are clearly some kind of sparse identifier, not the simple
> per-target unit serial number LUNs originally were.  I'm thus not sure
> that what the scsipi code calls a LUN is really the right abstraction
> to represent them; they feel to me more like unique spindle IDs such as
> we're going to want for wedges - I wonder if it might be better to
> introduce a mapping layer, so that most of the code uses small integers
> for LUNs, mapping between them and the 64-bit sparse values early on
> input and late on output.

LUN mappings are arbitrary, and often sparse.  Some devices use a bit
to separate out hardware LUNs (disks) from software LUNs (RAID volumes).
Other times you can have FCAL/parallel SCSI bridges where individual 
SCSI targets appear as LUNs attached to a single FCAL initiator, and 
the LUNs of the SCSI targets appear as additional LUNs as well.

One thing you really do not want to do is remap the 64-bit LUN to
an 8-bit LUN identifier since you will then lose all the geographical
information that allows you do identify what specific piece of target
hardware is associated with a LUN identifier.

The best way to do this is send out a REPORT LUNs to all devices
and fall back to the old scheme only when devices don't recognize
the command.  One benefit of this is that you may get faster
SCSI bus probing since you don't need to bother probing
non-exitent LUNs.  

You may also need a quirk for devices that die when they recieve 
the REPORT LUNs although I can't recall having stumbled across
such a device as yet.

Eduardo