Luis R. Rodriguez wrote:
On Tue, Nov 25, 2008 at 04:35:54PM -0800, Pavel Roskin wrote:
On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:
This is documented here:
http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat
I mean, I don't know how painful it can be. Perhaps it's better to
anticipate some requirements earlier than to change them later.
Its painful to add anything new. To understand this better it helps to
understand why some flags were added in the first place to regulatory rules.
The short and sweet answer is DFS. And the general rule of thumb goes like this:
When in a DFS freq, if you don't support DFS in your mode of operation,
then you cannot TX.
So if you don't support DFS in IBSS, you get NO-IBSS. If your AP doesn't
support DFS then you can't use DFS channels. If you don't support DFS
then you better not use active scanning on a STA, hence the passive scan
flag (I guess this should be renamed to NO-ACTIVE-SCAN to be more
consistent).
The NO-HT20 is historical, we're not aware of countries disallowing
this. No-HT40 is also a bit historical as it seems the countries which
do not allow this will soon allow for it.
The NO-OFDM and NO-CCK flag is unused and purely historical.
So before adding a flag I think its *really* good to think about it
thrice and see if there is a need of it, otherwise the answer should
usually be that its not a good idea to add it.
If anything we can consolidate flags or remove flags, that would be nicer
if possible.
I think
both "don't transmit" and "don't transmit unless permitted by the AP"
could be useful in some jurisdictions.
Don't transmit is implicit, CRDA just "allows", so the flags we have now
are all negative for special considerations on "allowing", such as NO
IBSS, etc.
This is simply not the case. Implicit is don't tune the radio, this
prevents both transmission and reception which needlessly limits useful
features of a device for no regulatory reason. This is why we are
discussing it.
A flag of "no-transmit" is likely accurate in most regulatory domains
and would allow driver developers to enable more advanced usage of the
devices (if they choose). I grant, most users really have no reason for
this and that is an acceptable reason for someone to refuse to take the
time to code it. If someone is willing to take the time to add the
flag, it should not be turned down as it is both accurate and proper to
support receive only frequencies.
thanks,
Rick Farina
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
