Re: [RFC] Asynchronous scanning for FC/SAS version 3

[Andrew Vasquez <andrew.vasquez@qlogic.com>]

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