Subject: Re: quick patch for LUNs on SCSI-I devices
To: Justin T. Gibbs <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 09/02/1996 13:44:37
On Mon, 02 Sep 1996 12:41:12 -0700
"Justin T. Gibbs" <firstname.lastname@example.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
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
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 email@example.com
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