Re: Configurable scan dwell time?

[Ben Greear <greearb@candelatech.com>]

On 11/05/2015 08:25 AM, Johannes Berg wrote:
>
>>> The thing though is that there are now use cases in the standard(s)
>>> that want/require doing this. So just adding it as a hint will run the
>>> risk of userspace (like wpa_s) using this "hint" for implementing newer
>>> spec functionality, testing on ath9k and hwsim and declaring that it
>>> works :-) And then we're stuck with this feature being used/advertised
>>> on older devices where it doesn't actually work.
>>
>> Scanning is already best effort.  Someone implementing this new hint
>> can just be aware of the limitations.  If nothing else, start a scan on
>> a known number of channels (or single channel), see how long it takes..then you know if the
>> driver is ignoring your hint or not.
>
> But if you were asked to measure something on that channel, for a given
> amount of time while scanning, you could reasonably implement it that
> way. If you don't really know how long the device is *actually* going
> to do this, then you can't rightfully say you implement that spec.
>
> You can't really start a scan and measure the time either since there's
> no guarantee the scan will start right away.

Grep for 'dwell_time' in ath10k driver dir...it is already using different
values (active 50, passive 150) than what mac80211 does, so anyone assuming scan time is exactly some
duration is already confused.

>>> Now, having those standard use cases is actually a good argument *for*
>>> adding them in the standard API, but I think we need to be more careful
>>> around these issues - perhaps having drivers indicate that they support
>>> it, maybe even with valid ranges, etc.
>>
>> I think that is vastly over-engineering the problem, but truth is, it
>> can always be added later if there is an actual need for that knowledge.
>>
>
> Well, not really. The only way for this to work would be to outright
> reject requests that weren't within the advertised ranges; doing this
> after already having the API would break existing clients thereof.

It wouldn't break clients if the value is known to just be a hint
from the beginning..ie clients cannot ever expect that this value
is guaranteed to be used.

But, if it would help this feature get upstream, then I will work on
adding a driver flag.  Would that make it acceptable for upstream?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com