On Fri, Oct 13, 2000 at 10:22:52AM -0700, Matthew Jacob wrote:
> 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.

Ok. I know this for IDE devices too :)

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

Ok.

> 
> > 
> > > 
> > > 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?

I can easily know, at the low-level driver, if there is a device or not.
But I wouln't mind to do the job at the IOCTL level :)

> 
> > 
> > > 
> > > 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!

Ok, that's clear.

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

Ho yes, I know ...

--
Manuel Bouyer <bouyer@antioche.eu.org>
--