On Mon, 02 Sep 1996 12:41:12 -0700 
 "Justin T. Gibbs" <gibbs@freefall.freebsd.org> wrote:

 > >No ... In the case where the device is "ancient", (i.e. version & 
 > >SID_ANSII == 0), LUNs are not checked, or in the case where a NOLUNS 
 > >quirk exists for the device.  In the case of ancient devices that _do_ 
 > >have working LUN support (i.e. the Emulex MD21), we have a FORECELUNS quirk.
 > 
 > Exactly.  So, the behavior now is to send the lun information to SCSI II
 > devices until we know that they are in fact SCSI II devices.  Hopefully
 > this doesn't break any SCSI II devices.
 > 
 > >Note that in the current model, the LUN won't get set on the first try of 
 > >the device, which will be LUN 0 ... unless the user explicitly 
 > >confgigured a device at lun 1 or something ...
 > 
 > It will get set, it will just be 0.

...which is just like the current "isn't set" behavior.  Yes, it's a 
side-effect, and it's Captical-I Icky, but... So is the entire way 
targets and luns are currently handled :-)  It's not clear that one can 
actually solve this _correctly_ without properly layering the target/lun 
code.

Yes, it deserves a big:

	/*
	 * XXX YOW!  THIS IS REALLY GROSS!
	 */

:-)

 > Hmm.  I wonder how SCSI->SCSI and SCSI->ESDI bridges will handle setting
 > the LUN in the CDB.  Hopefully it gets striped before getting sent to the
 > final device. 

Err, I have a sun3 with an MD21 SCSI->ESDI bridge at home ... When I get 
a chance, I'll try it out... I don't expect any problems ... I believe 
SunOS stashes the LUN in the cdb.

 > You still need to have the adapter export its maxtarget and maxlun
 > information in its attach args to the scsibus.  SCSI-III allows up
 > to 64bits for the target ID, LUN, and tag identifier with each
 > specific bus implmentation defining its own upper bounds <= 64.
 > In the code on my machine, this information is stored in the
 > adapter_link:

Why is an "adapter link" necessary?

Thusfar, my approach is to have a "scsi_attach_args" (under NetBSD, 
adapters export the "scsi" attribute, and scsibus's attach to that 
attribute, hence the name).  The scsi_attach_args will describe the 
properties of the controller; maxtarget, maxlun, openings, adapter scsi 
id, etc.  The scsi_attach_args don't need to provide a pointer to the 
adapter softc; when the scsibus is attached, it gets a pointer to the 
parent device, which is adapter, by definition.  Whatever info is 
provided by the scsi_attach_args will be stored in the scsibus_softc 
(which is where it belongs).

The same sort of thing will happen with the `tg' ... the whole notion of 
scsi_link will be gone forever (YAY!).  Well, this is not _strictly_ 
true; there is information which is more or less common to all scsi 
devices ... I was thinking of handling that in a way similar to how 
chipset drivers are handled ... i.e. a "scsidev_softc" which contains the 
struct device and the common info ... I have to put a little more thought 
into that part...

In any case all of the SCSI device state info will then he handled by the 
autoconfig system, and the data structures won't be so horribly overloaded.

 -- save the ancient forests - http://www.bayarea.net/~thorpej/forest/ -- 
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939