On 4-1-2017 11:30, Johannes Berg wrote:

quoted

However, we need to prefer something

quoted

-
always preferring the new sched scan could lead to bounces, so we
can
prefer (1) existing, (2) legacy-single type or (3) new-multi type,
but
not (4) new sched scan.

Not sure I can follow. What is the difference between (1) and (2). 

(1) would never cancel any existing sched scan, regardless of type
(legacy vs. multi-capable)

(2) would cancel an existing sched scan (in favour of a new one) if the
existing one is multi-capable

(3) would cancel an existing sched scan (in favour of a new one) if the
existing one is legacy type

yes, yes. sinking in :-p

quoted

Also
what do you consider (4) new sched scan. You mean the additional
parameterization of the scheduled scan?

No, I just meant any new request.

Yeah, so there is already an existing/active sched scan. Clear.

quoted

quoted

I think preferring the existing would probably be best, i.e. refuse
legacy if any sched scan is running, and refuse multi if legacy is
running?

Whatever the response above, I can understand this and it seems most
straightforward. So I tend agree this is our best option although
maybe for the wrong reason.

:)

Thanks for clarifying it.

Gr. AvS