Re: [RFC 0/9 v2] DFS/radar state/userspace handling

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2011-03-01 at 14:07 +0100, Bernhard Schmidt wrote:

> Sorry about that.. it should have read:
> "..that states are *now* global and no per wiphy.."
> 
> What I mean with that is that the interference flag/reporting, as
> well as the NOL is shared between all wiphys contrary to the previous
> version.

Oh, ok.

> > Finally, I think your code split is a little hard to understand. Is
> > there really any point in adding the code bit by bit into both cfg80211
> > and mac80211 at the same time? I'd rather see a few patches to make
> > cfg80211 complete and then implement it all in mac80211.
> 
> I tried to group them by functionality and not by subsystem. But if
> you prefer that I can make a large blob for cfg80211.

No, splitting them up seems alright, I just wouldn't split up the
mac80211 bits across. You'll also find that when it comes to advertising
capabilities, you need mac80211 to advertise them to cfg80211, and then
you only want to advertise it once all functionality is in place.

Now, for applying it might later make sense to just have a single patch
adding it, but it doesn't really matter as long as the code isn't really
used anyway since no driver advertises the capability.

> > Which brings me to another point -- there's no way to detect from
> > userspace whether or not this is all available.
> 
> True, the only thing available right now is checking the error code
> for CAC_START. I'll fix that.

One thing to keep in mind: I don't typically trust drivers, that is if
they don't advertise something cfg80211 won't allow it even if it might
still succeed. For example, if the driver doesn't advertise IBSS, but
would still permit adding IBSS, cfg80211 doesn't allow it. This makes
things more consistent and makes driver authors realise right away that
they need to advertise things.

johannes