On 14/11/12 12:23, Johannes Berg wrote:
On Tue, 2012-11-13 at 17:04 +0200, Victor Goldenshtein wrote:
No ... channel contexts are in the kernel now, so you do have to think
about it now.
Well thinking is one thing implementing is another ;)
Well ... :)
This whole DFS implementation initially intended for a single channel
mac. I don't might to deal with the channel context stuff but not sure
how much available time I"ll have for it, so it might take awhile.
I know there are people waiting for this, so I'm thinking would you
consider to go first with this single channel DFS support and later to
extend it to work with channel context stuff ?
Fair enough, but like I've been telling you, the current code doesn't
even match the current APIs.
Initially, I thought that for radar detection, you need to reserve the
channel context (in mac80211), make sure it's the only channel context
and prohibit other channel contexts from being added, until radar
detection is done.
However, then I realised that that still doesn't work -- once initial
radar detection is done, it needs to continue while the AP is active. If
the channel context was going to be relinquished, or even just the
channel changed for a few seconds, it would be unsafe. So as a result,
the radar detect operation has to somehow be coupled to the start AP
operation and prohibit channel changes and additional channel contexts
during the entire operation time.
Hmm.. cfg80211 doesn't really know about channel contexts.
The problem I see is that cfg80211 may be in a combination with
`num_different_channels = 1` and mac80211 can have 2 channel contexts
due to channel type incompatibilities.
We'd need to tell cfg80211 that multi-interface is not possible when DFS
is active if we want to at least consider single-channel only DFS.
-- Pozdrawiam / Best regards, Michal Kazior.
--
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
