On 5-1-2017 14:44, Johannes Berg wrote:

On Thu, 2017-01-05 at 14:39 +0100, Arend Van Spriel wrote:

quoted

Today we already have roaming offload, right? 

I guess - you defined the BSS selection stuff for it :)

Well I was referring to:
 3047         WIPHY_FLAG_SUPPORTS_FW_ROAM             = BIT(13),

quoted

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.

quoted

quoted

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.

To be clear: me neither ;-) On the same page here.

quoted

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.

fair enough.

quoted

quoted

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?

From what Dmitry listed I guess there's really only one. Early on in the

thread Luca gave some other examples of scan extensions so may need to
consider notification/dump methods that are extensible. It seems awkward
to have a single "initiate" command and a couple of
"notification/retrieval" commands. It may not be so bad as long as it is
clear which retrieval command goes with a notification.

Regards,
Arend