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, :-;.

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

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.

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.

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

What do you think?

On Wed, 11 Oct 2000, Manuel Bouyer wrote:

> Hi,
> in order to properly support tagged queuing in siop, I need to know if there
> is a device present at each target/lun, in order to free the resources
> when possible (most devices have only lun 0, so I don't need the script
> to handle each 8 luns for such devices). 
> One way to do this would be to spoof INQUIRY commands in the scsi driver
> to detect this. But I'd prefer to have the scsi layer tell the driver is
> the device is here or not after a probe.
> I've though about using an ioctl for this, called after each target/lun
> probe which would tell if the device is here or not.
> In the driver, once I know there is only lun 0 I could free the resources
> that have been allocated to probe the other luns.
> 
> I didn't look at this closely yet, but I'd prefer to get ideas before
> working on it :)
> 
> --
> Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
> --
>