On 4-1-2017 10:59, Johannes Berg wrote: > On Tue, 2017-01-03 at 13:25 +0100, Arend Van Spriel wrote: >> On 2-1-2017 11:44, Johannes Berg wrote: >>> >>>> + /* >>>> + * allow only one legacy scheduled scan if user-space >>>> + * does not indicate multiple scheduled scan support. >>>> + */ >>>> + if (!info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI] && >>>> + cfg80211_legacy_sched_scan_active(rdev)) >>>> return -EINPROGRESS; >>> >>> That probably doesn't go far enough - if legacy one is active then >>> we >>> probably shouldn't allow a new MULTI one either (or abandon the >>> legacy >>> one) so that older userspace doesn't get confused with multiple >>> notifications from sched scans it didn't start. >> >> I considered that although not taking the notifications into account. >> Will change it. Abandoning the legacy one would be a behavioral >> change so probably not acceptable, right? > > Well, it would be acceptable since it's documented that it's possible > it might stop for any reason. However, we need to prefer something - > 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). Also what do you consider (4) new sched scan. You mean the additional parameterization of the scheduled scan? > 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. >> I guess your remark means this clarifies your earlier question about >> the request id, right? > > yeah. Thanks, Arend
