On Tue, 2015-02-24 at 06:36 -0800, Ben Greear wrote: > We could push more and more of this to user-space and let it decide whether and > how to forward or accept frames for particular radios. Sure, no objection to that. However, just arbitrarily adding a "change channel" call, without thinking about the realities of the code already supporting multi-channel concurrency, remain-on-channel and hw-scan operations won't get us very far and just lead to issues with the API. > But, to do that, we need the low-level settings sent to user-space > (such as current channel). Encryption keys could be a future enhancement > here, so that we can do 'hardware' encryption in hwsim (and handle encrypt/decrypt > logic however we want in user-space). Sure. I'd just like to ask that the API is actually useful in more than the default single-channel support BSS-only case :) 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
