On 7-12-2016 19:39, Dmitry Shmidt wrote: > On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: >> >>> Indeed, results are results. I just want to take care of two things: >>> 1) Memory consumption - we can clear stale scan results for >>> connection, but not for location if we are using history scan. >> >> Well eventually we also have to clear for location if we run out of >> memory, that usually means dumping them out to the host, no? > > Being out of memory and consuming more memory are different > things, but I agree - maybe we don't need to worry about it. > >>> 2) Use of insufficient results for connection - in case we had >>> history or hotlist scan only for very limited amount of channels, >>> then we may not have enough APs in our result for "sterling" >>> connection decision. >> >> I'm not entirely sure about this case - surely noticing "we can do >> better now" is still better than waiting for being able to make the >> perfect decision? > > Maybe we can just keep flag saying that currently available results > were not received by usual full scan. > >>>>> Report: none / batch / immediate >>>> >>>> Not sure I see much point in "none"?? >>>> >>>> Can you define these more clearly? Do you think "batch" reporting >>>> should be like the gscan buckets? Or actually have full >>>> information? >>> >>> None - means that there is not need to report. It can be useful >>> in case of roaming scan, scheduling or hotlist scan - you didn't find >>> anything suitable - don't report that there is no scan results. >> >> But that seems more of a filtering thing, combined with "immediate" for >> anything passing the filter? > > We can use this approach as well. > >>>>> Request may have priority and can be inserted into >>>>> the head of the queue. >>>>> Types of scans: >>>>> - Normal scan >>>>> - Scheduled scan >>>>> - Hotlist (BSSID scan) >>>>> - Roaming >>>>> - AutoJoin >>>> >>>> I think somebody else said this but I didn't find it now - I think >>>> this would make more sense to define in terms of expected behaviour >>>> than use cases for each type of scan. >>> >>> I think Luca made this statement. >> >> Yeah - I just couldn't find it again on re-reading the thread :) >> >>> It is totally ok from SW point of >>> view - especially due to the fact that scan is scan. However, >>> I suspect it will be harder to handle from user experience. I mean >>> at the end wireless framework / driver / FW will convert special >>> scan type to usual scan with special params and response, but why >>> to put this burden on user? I don't think this will put burden on the user although it depends who/what you mean by this. If you mean the mere mortal end-user I would say no as indeed there must be some software entity (in user-space) that will have to initiate a nl80211 command with appropriate attributes according to whatever user-space is trying to accomplish. >> I just think it's more flexible and open-ended. The actual definition >> of the resulting parameters needs to be somewhere anyway - putting it >> into driver/firmware (vs. wifi framework or so) seems to duplicate it >> and certainly makes it harder to modify/extend in the future, no? > > So, let's summarize: > Instead of creating new type of generic scan with special types, > we want to go with additional expansion of scheduled scan options and > parameters (in order not to "multiply entities"), including ability to send > new scheduled scan request without stopping previous one. > > Is it Ok? Sounds ok. To me a generic scan command with type attribute is equivalent to having seperate commands for each type so there seems to be no gain. Now whether this all can be accomplished by extending the scheduled scan depends on the problem that you are trying to solve. Main purpose seems to be offloading different scanning tasks which could make scheduled scan a good candidate. Now I want to add gscan to this mix as it seems some concepts for that are in play in this discussion as well, eg. hotlist. gscan is like scheduled scan, but it supports multiple schedules. However, it is still a single request from a single user-space process. I think Luca mentioned supporting requests from different user-space processes. Is that also what you mean by "ability to send new scheduled scan request without stopping previous one" or is that still from a single user-space process. Do we need a limit to the amount of scheduled scan requests that can be handled simultaneously. A maybe more important aspect of gscan is user-space control of result reporting and thus the frequency of waking up host and/or user-space. I suspect this would be needed in the scheduled scan extension as well, right? Regards, Arend
