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. 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? > I guess your remark means this clarifies your earlier question about > the request id, right? yeah. johannes
