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