Hey Zefir,
On Tue, Jan 29, 2013 at 02:48:53PM +0100, Zefir Kurtisi wrote:
> On 01/29/2013 01:21 PM, Simon Wunderlich wrote:
> > From: Victor Goldenshtein <victorg@xxxxxx>
> >
> > [...]
> >
> > /**
> > + * enum ieee80211_dfs_state - DFS states for channels
> > + *
> > + * Channel states used by the DFS code.
> > + *
> > + * @IEEE80211_DFS_USABLE: The channel can be used, but channel availability
> > + * check (CAC) must be performed before using it for AP or IBSS.
> > + * @IEEE80211_DFS_UNAVAILABLE: A radar has been detected on this channel, it
> > + * is therefore marked as not available.
> > + * @IEEE80211_DFS_AVAILABLE: The channel has been CAC checked and is available.
> > + */
> > +
> > +enum ieee80211_dfs_state {
> > + IEEE80211_DFS_USABLE,
> > + IEEE80211_DFS_UNAVAILABLE,
> > + IEEE80211_DFS_AVAILABLE,
> > +};
> > +
> Not sure if IEEE80211_DFS_UNKNOWN is not missing here, i.e. whether a channel that
> never passed a CAC (or the CAC has been aborted) is always USABLE. Once I realized
> why ETSI defined an UNKNOWN state, but forgot meanwhile - so maybe only relevant
> for managed operation (like an UNKNOWN state can be overridden by external
> information, whereas e.g. UNAVAILABLE can't).
I've seen the UNKNOWN state in your last mail and your last slides, but didn't see
a purpose for it. If you can remember what we need it for, please tell me. :) We could
reject changes for an UNAVAILABLE channel from outside access if this is required.
>
> Furthermore, is there a reason to define an additional wireless_dev.cac_started
> flag vs. adding a IEEE80211_DFS_CAC state?
We have discussed that we want to move cac-information from channel into wdev, so I
just did that.
The idea was that a CAC can always be started, and state transition is only performed
after a succesful CAC. This simplifies the state machine and some corner cases. A
channel stays USABLE through the CAC, and is only changed to AVAILABLE after CAC is
completed. We also don't forbid checking the same channel on different WiFi modules,
if any of them completes the channel is changed to AVAILABLE.
The same goes for the OPERATING state (defined in ETSI at least) - I don't have this
as dfs state, because it is just the same as AVAILABLE plus the information that
we currently use it, and that we know in the driver. Adding the state would just
add management overhead with no practical gain, IMHO.
Cheers,
Simon
Attachment:
signature.asc
Description: Digital signature
