On Mon, 2008-10-20 at 19:37 -0700, Luis R. Rodriguez wrote: > As I mentioned in my previous e-mail, the real problem is what you are > asking for changes the entire regulatory design from: "disable > everything and enable only this" to "enable everything except for > elements I don't define in the band I tell you to". I don't think I agree. > There are many > design flaws with this; an obvious problem to this is what is a band? > In my patch I took the liberty to define that a frequency is part of a > band if a rule was present within 2 GHz of itself. This works but it > is trying to make a definition out of something that doesn't exist -- > its trying to solve the wrong problem. Since regulatory database is in > KHz it is designed to allow us to grow regardless of band notions or > associations. In the regulatory database we allow for 2 GHz, 5 GHz, > etc KH definitions for any country and this was designed to account > for misinformation on drivers to help the user be more compliant. By > changing the design to what you are suggesting you'd have to add a > dummy rule for every frequency "band" if you really want to disable > all other bands. Yes, this is a problem, but then again it's fairly well-defined which is 2.4 and which is 5 GHz band, and it probably doesn't matter much at this point. cfg80211 _has_ a notion of bands. If we really wanted to have band-specific hints to let a driver say "nay, sorry, I know nothing about 5 GHz" then we can I think do this, subject to a few constraints: * first hint that contains a band wins this band * without any other information, a band that we know nothing about is disabled (just like the default state would be when we know nothing at all) This ought to be possible, maybe by simply moving from regulatory_hint(alpha2, structure) to regulatory_hint(alpha2) regulatory_struct_hint(structure, bandflags) where bandflags can be BIT(IEEE80211_BAND_2GHZ) or BIT(IEEE80211_BAND_5GHZ). It would be fairly easy to keep track of that information and build a common struct. No need to even bother looking at the frequencies, when you have a 2GHZ hint and get a 5GHZ one you simply add all the rules from the new hint. Yes, that could be abused to add more 2GHz rules, but we can "police" that code. And it can only be abused once because when the bit is already set we ignore the hint anyway. > The proper solution is to either add 5 GHz regulatory rules to your > regulatory_hint() I strongly disagree with that. It's not correct in any way. > and/or rely on crda to enable the 5 GHz channels > required for the country the user is in. It is true that you need > manual intervention and the way I am trying to resolve that is not by > changing the design of the current regulatory infrastructure, instead > I want to add country selection support to say wpa_supplicant or > Network Manager. That, IMO, is how to address the problem correctly. This is, of course, the solution for !EMBEDDED, but I don't think that's really what we're talking about. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
