On Tue, Nov 25, 2008 at 07:10:07PM -0800, Richard Farina wrote: > 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. Passive scan | NO-IBSS should suffice. And to be clear NO-IBSS should probably be renamed to NO-BEACONING. 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
