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 ?

> 
> 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 :)

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

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

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

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

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