Re: [PATCH 4/8] scsi: libsas: trigger a new revalidation to discover the device

From: Jason Yan
Date: Sun Jun 03 2018 - 21:02:07 EST

On 2018/6/1 18:02, John Garry wrote:
I mean that since libsas does disocovery/revalidation for all expander
PHYS for a single event, than all discovery/revalidation should be
synchronised with that same event. I don't mean that for a given
expander PHY which originated a broadcast event, the
revalidation/discovery for that PHY should be synchronised with that
same event. Like you said, I don't think it's possible.

On another point, one of the reasons to synchronise event processing was
so events are not lost and are processed in order. In principle, by
chaining these bcast events we lose that, since other PHY events may be
queued before we queue the new artificial bcast events.

I got what you mean. I will try to keep the principle of synchronised event processing.

But if you mean we shall do this device removing and rediscovering in
one revalidation if it is not a "flutter", I think we can wrap a new
function for sas_revalidate_domain(), such as:

while (need_to_revalidate_again)
need_to_revalidate_again = sas_revalidate_domain()

In this way the sas_port adding/removing is packed in one loop, we won't
have the annoyance of "duplicate filename" warning. What do you

Something like that, where all the discovery/revalidation and related
device + port processing is done before we complete the revalidation
event processing. A single revalidation event may defer do device+port
processing multiple times.