linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Review of moving all DFS parameters to userspace
Date: Mon, 14 Feb 2011 16:39:48 +0100	[thread overview]
Message-ID: <4D594CC4.9020906@neratec.com> (raw)
In-Reply-To: <20110201173247.GE2560@tuxdriver.com>

On 02/01/2011 06:32 PM, John W. Linville wrote:
> On Tue, Feb 01, 2011 at 08:38:05AM -0800, Luis R. Rodriguez wrote:
>> I though we had reviewed the possibility of moving DFS parameters to
>> userspace but it seems that's not the case. We now at least know we
>> can keep the DFS regions: US, JP, ETSI, the next step is to determine
>> if the DFS parameters for these regions will come from userspace or
>> kernelspace. I'm inclined to support starting off with moving this to
>> kernelspace just to let us move forward with this support, and once in
>> kernel, review the possibility to move this out to userspace.
>>
>> Thoughts?
> 
> Seems like a reasonable approach for the short term...better than
> locking-in userland ABI...
> 
> John

Sorry, I was not aware that the userspace DFS approach was already discussed 
and rejected. I missed two IRC meetings in January and reading [1] sounded 
to me that potential approaches are still evaluated.

Anyhow, I meanwhile posted both approaches (kernel vs. userspace) that are 
equivalent from functional point, assuming that a HW independent pattern 
matching is what we need to implement for DFS radar detection.

This in fact is still an open issue: Atheros claimed that detection is 
HW-dependent while we have got up and (maybe not-so-perfectly ;)) running 
HW-independen radar pattern detection. We are still waiting to get Atheros' 
pattern detector source code to evaluate detection performance and finally 
prove the benefit of a HW dependent implementation.

Until then (and since the DFS activities degraded lastly) we will continue 
fine-tuning our detectors based on the proposed design and move to the 
finally chosen architecture as soon as an agreement is reached.



Cheers
Zefir



[1] http://linuxwireless.org/en/developers/DFS/#DFS_events

  reply	other threads:[~2011-02-14 15:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01 16:38 Review of moving all DFS parameters to userspace Luis R. Rodriguez
2011-02-01 17:32 ` John W. Linville
2011-02-14 15:39   ` Zefir Kurtisi [this message]
2011-02-15  0:48     ` Luis R. Rodriguez
2011-02-15  2:33       ` Felix Fietkau
2011-02-15 12:16         ` Zefir Kurtisi
2011-02-15  9:23       ` Zefir Kurtisi

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=4D594CC4.9020906@neratec.com \
    --to=zefir.kurtisi@neratec.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@gmail.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).