Re: Configurable scan dwell time?

[Johannes Berg <johannes@sipsolutions.net>]

> > 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.

> > 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.

johannes