On 02/24/2015 06:40 AM, Johannes Berg wrote: > 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. I took a look at the hw-scan code a bit...I guess we might could do additional info calls to user-space as we iterate through the channels while scanning? A real driver would be causing the NIC to change channels at these junctures, either by directly setting registers or sending some message off to the target NIC's cpu, right? I would assume that off-channel work could do similar logic. Is that the sort of thing you had in mind? Thanks, Ben >> 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 > -- 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
