On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
[off-list ref] wrote:

On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:

quoted

These add per-scan request controls for optional behaviours we've found
useful (they've been in Chrome OS for a long time).  A patch for iw will
follow separately and the mods for wpa_supplicant are in our repo and
I'll push them to Jouni if these are accepted.

Sam Leffler (3):
  {nl,cfg}80211: add a flags word to scan requests
  mac80211: add support for tx to abort scan requests
  cfg80211: add support for flushing old scan results

I like the flushing one, but I'm not so sure about the TX abort thing.
How do you suggest to handle that when scanning is offloaded to the
driver and/or firmware? Especially given that multi-channel is going to
require a firmware implementation, I'm not sure how to achieve good
behaviour across the different implementations.

Maybe it'd be worthwhile to go for a more generic approach, marking
scans as "low priority" or "high priority" or similar, and then
implementing such behaviour based on such settings? Our device for
example has a notion of "background scan" vs. "forced scan", which
behave differently in the firmware, and it would be useful to be able to
use these different behaviours. However, I can't say that "TX abort"
would be a guaranteed scan behaviour for a "background scan".

we also have some "urgency" option in our hw scan, but we currently
never use it (not really sure when it should be used... maybe for
roaming on beacon loss?)

the TX abort is relevant mainly for sw scan.
i'm not sure we really want to couple it with scan priority, though.
otoh, userspace doesn't really care (or know) if we use sw or hw scan,
so configuring it all with a single "scan priority" option does make
sense.

Eliad.