From: Johannes Berg <johannes@sipsolutions.net>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: Janusz Dziedzic <janusz.dziedzic@tieto.com>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] cfg80211: introduce regulatory wide bandwidth flag
Date: Fri, 31 Jan 2014 14:42:14 +0100 [thread overview]
Message-ID: <1391175734.4141.12.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CAB=NE6XysGH36Jep4xxqQZPmFM=AR6akcb-REWPW93H4y68=tQ@mail.gmail.com> (sfid-20140130_014204_336610_4613A623)
On Wed, 2014-01-29 at 16:41 -0800, Luis R. Rodriguez wrote:
> > The only thing I could think of an optimiser doing is combine ranges,
> > but then it would lose flags which can't be right.
>
> One thing is in-kernel rules, another is wireless-regdb. If you are
> extending rules in wireless-regdb you may at times run into a
> situation where two rules are contiguous and you know you can combine
> them and want to, combination for example makes sense if your source
> for the db has a set of contiguous frequency rules with the same
> power, max eirp, and flags. That's what the optimizer available as a
> library does in reglib, part of CRDA.
My point mostly is that due to how the rules are interpreted (a single
channel must fit into a single frequency range), this isn't just an
optimisation, it actually has impact on the behaviour. So calling it an
'optimizer' is misleading, that implies that it's actually always
desired to do this, which isn't necessarily the case (it's quite likely
the case, and IMHO the old interpretation rules are stupid, but those
are what we're stuck with.)
johannes
next prev parent reply other threads:[~2014-01-31 13:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 12:43 [PATCH v2 1/3] cfg80211: add helper reg_get_regdomain() function Janusz Dziedzic
2014-01-22 12:43 ` [PATCH v2 2/3] cfg80211: introduce regulatory wide bandwidth flag Janusz Dziedzic
2014-01-23 15:57 ` Johannes Berg
2014-01-25 0:32 ` Luis R. Rodriguez
2014-01-25 0:36 ` Luis R. Rodriguez
2014-01-25 10:29 ` Janusz Dziedzic
2014-01-29 13:10 ` Johannes Berg
2014-01-30 0:41 ` Luis R. Rodriguez
2014-01-31 13:42 ` Johannes Berg [this message]
2014-01-22 12:43 ` [PATCH v2 3/3] cfg80211: parse WIDE-BW flag for internal regdb option Janusz Dziedzic
2014-01-25 0:34 ` [PATCH v2 1/3] cfg80211: add helper reg_get_regdomain() function Luis R. Rodriguez
2014-01-28 19:23 ` Janusz Dziedzic
2014-01-28 19:42 ` Luis R. Rodriguez
2014-01-29 8:17 ` Johannes Berg
2014-01-29 9:44 ` Luis R. Rodriguez
2014-01-29 9:46 ` Luis R. Rodriguez
2014-01-29 9:58 ` Johannes Berg
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=1391175734.4141.12.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=janusz.dziedzic@tieto.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@do-not-panic.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