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

Because FreeBSD doesn't have new config yet.  Perhaps I should simply
change the name from adapter_link to scsi_attach_args to make the
migration smoother.

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

And is where it is in FreeBSD too.  A scsi_bus looks like this:
/*
 * One of these is allocated and filled in for each scsi bus.
 * it holds pointers to allow the scsi bus to get to the driver
 * That is running each LUN on the bus. 
 * It also has contains a pointer to information about the adapter   
 * driver that controls this bus, and the queue that manages all
 * devices on this bus.
 */     
struct scsi_bus { 
        struct    scsi_adapter_link adpt_link;
        struct    scsi_queue *scsiq;    
        int       scsibus_unit;         
        struct    scsi_link *(*scsi_link)[8]; /* dynamically allocated */
};

I just decided to package all of the adapter specfic crud into one structure.

How does new config deal with default parameters (or does it)?  The current
strategy I'm using in FreeBSD looks like this:

int
bt_attach(bt)
        struct bt_data *bt;
{       
        struct  scsi_bus *scbus;
        struct  scsi_queue *scsiq;
        
        btprobing = 0;
        /* 
         * Allocate resource queue.
         */
        scsiq = scsi_alloc_queue(BT_CCB_MAX);
        if (scsiq == NULL)
                return 0;

        /*
         * Prepare the scsi_bus area for the upper-level
         * scsi code.
         */
        scbus = scsi_alloc_bus(&bt_switch, bt, bt->unit, scsiq);
        if (scbus == NULL) {
                scsi_free_queue(scsiq);
                return 0;
        }
        /* Override defaults */
        scbus->adpt_link.adpt_target = bt->bt_scsi_dev;
        scbus->adpt_link.adpt_flags = bt->bt_bounce ? SADPT_BOUNCE : 0;
        /*
         * XXX Implement tagged queueing
         * scbus->adpt_link.adpt_tagged_openings = ???;
         */
        /* 
         * XXX scbus->adpt_link.adpt_magtarg should be adjusted for Wide cards
         * if(bt->type & BT_WIDE)
         *      scbus->adpt_link.adpt_maxtarget = 15;
         */

        /* 
         * ask the adapter what subunits are present
         */
        scsi_attachdevs(scbus);
        return 1; 
}               

I guess you could do the same thing by allocating the scsi_attach_args instead
of the scsi_bus directly.  The reason I've done it this way is to allow for
the structure to grow to support future SCSI features without having to update
all the old clients of the interface.

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

I've already shrunk the scsi_link in my current code, but I'm not
done yet.  You're definitely not the only one who was/is sick of
the scsi_link structure.

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

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================