On Tue, 2016-02-23 at 18:21 +0800, Hannes Reinecke wrote: > On 02/22/2016 07:39 PM, Seymour, Shane M wrote: > > Hi Hannes, > > > > How do you know that a request for an async scan is complete (I'm assuming that you get > > add or change udev events)? Assuming that someone has manually started a scan on something > > (e.g. some newly presented devices after boot) and all scans are going > to be async how > > do you when it is complete rather than waiting in a work queue? An > example may be a sysfs > > file that contains unscanned, pending, scanning, scanned so you know > when it's complete > > at the appropriate level in sysfs (the hba and the rports) so you know > when can continue > > if you're polling the status (e.g. checking as part of system admin > work with newly > > presented rports so you can then do something with them). > > > Thing is, I don't. > > We have had a similar discussion with the IBM zfcp folks, that it would > be desirable to have a marker in sysfs telling us that the rport is > stable (ie no scanning in progress). > However, this cannot be at the rport level (as the rport itself might be > going away), but rather at some higher level (eg fc_host). I am not sure this really helps. If another process initiates a scan then sysfs might report that the scanning was still in progress. If scans are initiated often enough, you might never observe a stable state. > > But this has nothing to do with the patchset, right? > We're just disabling the (existing) scan callback, and retrigger it once > the sysfs attribute has been cleared. > > We don't change the behaviour during scanning with this patchset. > > Cheers, > > Hannes -- 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
