On Wed, 22 Nov 2006, Matthew Wilcox wrote:
> On Wed, Nov 22, 2006 at 08:19:26AM -0800, Andrew Vasquez wrote:
> > +static int
> > +qla2xxx_scan_finished(struct Scsi_Host *shost, unsigned long time)
> > +{
> > + scsi_qla_host_t *ha = (scsi_qla_host_t *)shost->hostdata;
> > +
> > + if (!ha->host)
> > + return 1;
> > + if (time > ha->loop_reset_delay * HZ)
> > + return 1;
> > +
> > + return atomic_read(&ha->loop_state) == LOOP_READY;
> > +}
> >
> > is the *first* instance where the firmware/driver has attained a
> > steady link state within the topology. The 'found all the devices
> > there are to find' case may or may not fall within this window...
>
> Ah, fair point, I didn't *quite* understand the distinction between the
> various flags; can you suggest a better condition to test?
I don't really think there's a 'better' condition to test for given
there's isn't a state at which a driver:
- knows how to define 'all devices'
- is in control of ports beyond its single interconnect (as is
the case of a fabric) from the HBA to the switch port.
My only point is that when the LOOP_READY state is attained for the
first time, we'll have only discovered devices (ports) present at
precisely that point in time -- i.e. two seconds (one second, 10
miliseconds) later (perhaps due to some hiccup on the fabric) an RSCN
could occur, an SNS rescan performed, and some new target-capable
device is discovered...
Anyway, just something we need to keep in mind going forward... It's
also another reason why lun-discovery is triggered indirectly during
an fc_remote_port_add()...
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
