On Mon, Feb 14, 2011 at 7:39 AM, Zefir Kurtisi <zefir.kurtisi@xxxxxxxxxxx> wrote: > 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. 19:14 < *nbd> initially the pulse pattern matching will be somewhat hw specific 19:14 < *nbd> or at least driver specific So ideally if we can generalize things great, I really did not think we'd be able to get there on a first step. > 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 That's cool ! However I was told that for some parameters you might see some values programmed into hw which won't immediately make sense given that the programmed values are there in consideration for a hardware quirk of some sort. Mahboob, what parameters were those? > 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. That's being baked with legal. > Until then (and since the DFS activities degraded lastly) we will continue > fine-tuning our detectors based on the proposed design Driver or userspace? > and move to the > finally chosen architecture as soon as an agreement is reached. Sorry for my delay on the first set of patches, I hope to send a v2 hopefully by tomorrow.. Luis -- 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
