> On Wed, Oct 11, 2000 at 09:38:42AM -0700, Matthew Jacob wrote:
> > 
> > Actually, I've been doing some thinking about this. What I want(ed) to do is:
> > 
> > a) After an Inquiry for lun 0 succeeds, issue a REPORT LUNS command IFF the
> > devices is >= SCSI2. This will give us a map of all supported luns (it can be
> > sparse). If NT supports this, you would think that *BSD could too, :-;.
> 
> I don't have this command in the SCSI2 draft I have here, and doesn't seem
> to be defined in scsipi either. Could you add definitions for it to the
> NetBSD code so that I could try to use it ?


It's a SCSI-3 command, but like a lot of commands that come in with a new
version of the spec, devices claiming compliance with a lower level just
support it.


> 
> > 
> > b) If the REPORT LUNS command fails, then probe the luns up to the correct
> > one of:
> > 
> > 	quirk as set in quirk table (can be wider than 8 luns but < maxlun)
> > 	8 luns (per SCSI2 spec)
> > 	maxluns width as reported by the HBA
> 
> This means change the quirk table I guess :)

Hrmm... No- not really. We have an SDEV_NOLUNS now. All we need is a flag that
SDEV_ANYLUNS to indicate that asking for luns past 7 won't cause the device to
do something stupid.

This is primarily so you can flag things like the A1000 and other RAID units
that have 32 luns, or Veritas Storage Appliance (that's me!) that you can
have at least 256 luns on, as something to probe.

> 
> > 
> > c) Then, to accomodate what you want, I suggest and ioctl that constructs a
> > dataset like that reported via REPORT LUNS that can be shipped down to
> > establish lun support. I suppose we could also send this if there is no target
> > here also- it would be a null lun list.
> 
> Shouldn't we always have at last LUN 0 ? Anyway I could have some use for
> an IOCTL that would completely remove a device.

If there's nothing at that target, unless you're re-probing, why retain
anything?

> 
> > 
> > d) Now comes the more tricky part- we have to remove the fixed lun width
> > indexing we now use and construct a per target/bus lun width list for scsi
> > device structures.
> 
> If the LUN index can be higth this is certainly a good plan.

The Qlogic fibre channel f/w in place now is the SCCLUN. That's 65535
luns. Clearly a sparse map is needed!


> > We have to be careful about #c- one thing I ran into in AIX (with their
> > NCR/Sym/LSI implementation) is that if you forget to 'start' (via an
> > IOCTL) the device/lun and throw a command at the midlayer- boom! the infamous
> > three flashing LEDs from hell (AIX equiv of blue screen of death).
> 
> Sure, for now I dynamically allocate resources at the first command. So
> this should take care of it.

Yes.

> 
> > 
> > What do you think?
> 
> Look good, but I'm not sure I want to do such big changes yet: I'd like to
> have my siop changes pulled up for 1.5.1, so I'd prefer to not touch
> a lot of things in scsipi. Using REPORT LUNS can be a win, however.


It's on my list. You know- that list that always seems to mean that unless
it's required by a customer, you get to this about 2AM on a Monday morning....

-matt