Matthew Wilcox wrote:
On Mon, Jul 24, 2006 at 09:46:06AM -0400, James Smart wrote:
- I disagree with the handing off of a function pointer, with no real
bounds on it's "lifetime". There are windows with the current code
that if the driver were to then fail attachment and tear down
the shost, it would lead to bogus function calls, as well as
threads, etc that are essentially orphaned.
Can't happen; we take a reference on the shost and only release it once
it's done:
data->shost = scsi_host_get(shost);
True for the scsi host data structure itself. But, not true for the driver
which has essentially torn down the contents of the data structure and
killed the adapter, making the state checking code perhaps erroneous...
and if the state checking code is hosed, then the thread may never get a
positive, so it and the async scan is hanging out...
I'm open to this. I think what I'd prefer to see is the FC drivers
setting a SHT->scan_finished() method, then calling scsi_scan_host()
which would then do something completely different for drivers which
have a scan_finished method than it would for SPI drivers.
Isn't it enough that they (essentially via the transport) are calling
scsi_scan_target() ? We should be able to handle it there.
Calling scsi_scan_host(), with non-async scan enabled, doesn't seem the
right thing.
Yes, indeed. It occurs to me that the async scanning code does actually
give us a chance to sort devices before they get added to sysfs (and
named). I don't understand the exact problem that FC has, but this
could give us back the sort order that you had when you were doing your
own discovery, right?
Not really. And it really has nothing to do with the before and after of
your patch. What you propose just suffers from the same realities for FC.
Basically, you have no guarantee that:
- All devices are up and ready for discovery list when you go to probe.
They may not show up for a little while while the device or link settles.
- There is any repeated order in which the rports are reported to you
via the nameserver lists
- nor how fast the targets respond to your discovery requests
and is compounded by whether the driver/firmware does discovery in parallel,
how it processes addresses and nameserver lists, and by the target id's
being non-persistently assigned at each boot.
Clearly I haven't done a good enough job explaining how this patch
works. I'm going to do a design document now ...
I didn't think it was that bad. And perhaps my missing your tutorial with
Andrew/Eric was my problem.
-- james s
-
: 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
