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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
