Subject: Re: 64-bit LUN support
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 01/07/2005 08:00:22
> 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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B