linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, lrodriguez@atheros.com,
	nbd@openwrt.org, dubowoj@neratec.com, zefir.kurtisi@neratec.com,
	simon.wunderlich@saxnet.de
Subject: Re: [RFC 0/9 v2] DFS/radar state/userspace handling
Date: Tue, 1 Mar 2011 14:07:12 +0100	[thread overview]
Message-ID: <201103011407.13171.bernhard.schmidt@saxnet.de> (raw)
In-Reply-To: <1298982486.6015.10.camel@jlt3.sipsolutions.net>

On Tuesday, March 01, 2011 13:28:06 Johannes Berg wrote:
> On Mon, 2011-02-28 at 17:40 +0100, Bernhard Schmidt wrote:
> 
> > Implemented so far is the complete state machine, handling CAC and NOL
> > as well as starting appropriate action in hostapd. Note, this is based
> > on top of the 'dfs region support' work posted by Luis.
> 
> I'm not quite sure about all of this. First of all, you don't really
> explain the global state vs. local state but you did say that you no
> longer had global state, which clearly isn't true.

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.

> Also, what's the point in "struct radar" if there's only a single
> instance of that, which is global? I'd rather have multiple global
> variables I think -- but that might just be a matter of personal taste
> or choice.

Yeah, that 'struct radar' can be split up and moved into radar.c as
static vars.

> 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.

> 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.
 
> Finally, such details like not needing a timer -- a delayed work should
> be sufficient, etc.
> 
> johannes
> 
> 

-- 
Best regards,

Dipl.-Inf. (FH) Bernhard Schmidt (software development)

saxnet GmbH, Willy-Brandt-Ring 1, 08606 Oelsnitz
Tel. +49 (0) 3741 300 6. 100 - Fax +49 (0) 3741 300 6. 101
managing director: Steffen Dreise - county court Chemnitz - HRB 23017
http://www.saxnet.de

  reply	other threads:[~2011-03-01 13:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-28 16:40 [RFC 0/9 v2] DFS/radar state/userspace handling Bernhard Schmidt
2011-02-28 16:46 ` [PATCH 1/9] [mac80211] add method to access oper chan Bernhard Schmidt
2011-03-01 12:11   ` Johannes Berg
2011-02-28 16:47 ` [PATCH 2/9] [{mac|nl}80211] Add 2 new radar channel flags Bernhard Schmidt
2011-03-01 21:54   ` Luis R. Rodriguez
2011-03-02  8:25     ` Johannes Berg
2011-03-02  9:37     ` Bernhard Schmidt
2011-02-28 16:47 ` [PATCH 3/9] [mac80211] enable radar detection Bernhard Schmidt
2011-03-01 21:56   ` Luis R. Rodriguez
2011-02-28 16:48 ` [PATCH 4/9] [cfg80211] add preliminary radar processing code Bernhard Schmidt
2011-03-01 12:17   ` Johannes Berg
2011-03-01 21:58   ` Luis R. Rodriguez
2011-03-02  7:32     ` Bernhard Schmidt
2011-03-02 16:26       ` Luis R. Rodriguez
2011-02-28 16:49 ` [PATCH 5/9] [cfg80211] channel availability check (CAC) support Bernhard Schmidt
2011-02-28 16:49 ` [PATCH 6/9] [cfg80211] no operation list (NOL) support Bernhard Schmidt
2011-03-01 12:19   ` Johannes Berg
2011-02-28 16:50 ` [PATCH 7/9] [cfg80211] abide channel closing time Bernhard Schmidt
2011-02-28 16:51 ` [PATCH 8/9] [{cfg|nl}80211] announce flag changes to userspace Bernhard Schmidt
2011-02-28 16:51 ` [PATCH 9/9] [cfg80211] interference reporting Bernhard Schmidt
2011-03-01 12:28 ` [RFC 0/9 v2] DFS/radar state/userspace handling Johannes Berg
2011-03-01 13:07   ` Bernhard Schmidt [this message]
2011-03-01 13:15     ` Johannes Berg
2011-03-01 13:26       ` Bernhard Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201103011407.13171.bernhard.schmidt@saxnet.de \
    --to=bernhard.schmidt@saxnet.de \
    --cc=dubowoj@neratec.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lrodriguez@atheros.com \
    --cc=nbd@openwrt.org \
    --cc=simon.wunderlich@saxnet.de \
    --cc=zefir.kurtisi@neratec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).