On Thu, 2017-01-05 at 14:39 +0100, Arend Van Spriel wrote:
> Today we already have roaming offload, right?
I guess - you defined the BSS selection stuff for it :)
> Roaming scan would indeed
> be the same if roaming offload is not used unless you would want
> cfg80211 to make the decision, but then I would expect parameters for
> making that decision in the request. Same/similar for autojoin.
Right.
> > Actually I think I'm just misinterpreting your wording - you mean
> > that we can use the different final actions for the different scan
> > types, not that we should actually say - in driver/firmware/... -
> > "this is a history scan because the action is to report buffer
> > full", right?
>
> Do we care? The scan engine in our firmware does have use a scan type
> concept, but that is hidden by the firmware api. I guess your point
> would be that if user-space would prefer scan types and
> driver/firmware uses that as well, we might do the same in
> cfg80211/mac80211. How can we assure the scan types we come up with
> match those employed in any and all wireless devices/firmwares.
To be clear: I *don't* like having scan types in the APIs. I think it
muddies the waters and makes it less likely people will implement it
precisely as requested, because they'll argue "this is only for roam,
we'll implement our own magic there" etc.
> As Johannes points out it needs to be clear to user-space what its
> next step should be in obtaining results. Does it make sense to have
> a separate notification for the history scan results (not calling it
> that of course :-p ) triggered by the action "Report when buffer is
> full / almost full" or should user-space determine what to do based
> on request id that would be included in the (scheduled) scan results
> notification.
Yeah, that's a good question - based on the current behaviours etc. I
was assuming it'd be a new notification/result type.
> > There's a bit more complication wrt. the level of detail in results
> > though - sometimes the result may include all IEs (normal/sched
> > scan),
> > sometimes it may not ("history scan") - are we sure we really only
> > need
> > one new get_scan_results()?
>
> So could the "all IEs" case not be handled by the existing BSS
> storage? Is it still our intention to handle normal scan (no interval
> provided?) as well in the universal scan approach.
Yes, the "all IEs" (essentially "all information") case is handled by
the existing storage/dump methods/etc. but obviously the other cases
can't be - so my question was if there's really only one more other
case, or if we might have more new cases - or something that's flexible
wrt. the data we get?
johannes
