Hey Zefir,
On Tue, Jan 29, 2013 at 02:14:26PM +0100, Zefir Kurtisi wrote:
> On 01/29/2013 01:21 PM, Simon Wunderlich wrote:
> > [...]
> >
> > The channel states are now implemented in cfg80211. Shall we inform userspace
> > about channel changes? If yes, how should we do that? We could add channel states
> > to the channel list, and give "channel list changed" events to userspace as it
> > happens now, or define a new kind of event ("channel-available-again-event").
> > Suggestions welcome. :)
> >
> An event whenever a channel state changes is perfect, ideally provided with the
> time-stamp when this change happened.
Yeah. "channel list changed" events are already available (at least I get them in
hostapd). If we put the current state + timestamp when entered into the channel list,
we would have what you want, too.
>
> With the centralized channel state handling proposed here, the required
> modification to allow managed DFS operation can be minimized to a proprietary (or
> even upstreamed but CONFIG_CFG80211_CERTIFICATION_ONUS guarded) function to modify
> channel states.
Yes, the idea is that one can have a small proprietary patch or default-off command
(CONFIG_CFG80211_CERTIFICATION_ONUS sounds good) or something like that to change a
DFS state with the new cfg80211 function. I also thought about having a nl80211-command
without implementing an iw counter part or keeping a special "state change" program
somewhere with appropriate warnings. But this might still be too "liberal" for the
regulatory statement. :)
>
> Can't contribute much to code review, but full ACK for the updated concept.
>
Cool, also thanks for the code comments!
Cheers,
Simon
Attachment:
signature.asc
Description: Digital signature
