On Fri, Sep 28, 2012 at 3:57 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2012-09-27 at 09:39 -0700, Sam Leffler wrote: > >> > 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". >> >> Having a priority mechanism or similar would be fine. I usually >> hesitate doing the generic thing because the actual semantics can very >> so significantly from driver to driver that applications may end up >> having to build in knowledge of which driver is being used to get what >> they way want. But in fact what you suggest is how txabort is used--we >> mark wpa_supplicant bgscan's w/ txabort while fgscan's are not marked >> in this way. > > Yes, I agree it's a slippery slope, however with all the different > mechanisms that can be built in drivers/firmware/... I'm not really sure > how else to treat them? > > In theory we could say that we have > * TX abort > * Intel BG scan (otherwise opaque, in firmware) > * TI BG scan (otherwise opaque, in firmware) > * ... > > as separate flags/settings/..., but ultimately it seems that all that > would happen is that everybody would patch the supplicant to use their > mechanism for background scanning if available. Then, in theory, the > supplicant would know which one it's using, but since it doesn't really > know the semantics it doesn't really make a difference? > > Maybe we should agree on a few basic rules for the "generic" BG scan, > but I'm not sure what sensible rules would be. They can't be rules on > reliability, as then "tx-abort" wouldn't be a valid implementation > (unless you retried, but that could literally run forever), and I'm not > sure what other kind of rule would make sense. Either way, the > supplicant is going to have to assume that a finished "BG scan" has a > smaller result set than a "regular" scan ... > > There might be value in having more information about the actual "abort > due to TX" (whether it happened or not), but again that would be tied to > the specific implementation, and I'm not sure how to formulate any such > thing more generically. Right now, I don't even know how our or TI's > implementation behaves differently for the different types of scan. In my experience the reason why a bgscan was aborted is not important; you just want to know true/false so you know if you have a "complete picture" of the environment to make decisions. I also find the abort model much preferable to extending the scan work because unless results are sent back immediately you can easily end up sending back stale results. -Sam -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
