On Thu, Jun 12, 2008 at 06:19:38AM -0700, Johannes Berg wrote: > > > > > + * @NL80211_CMD_GET_REG: Get current regulatory domain, this is a query > > > > + * to the kernel wireless core, the wireless core returns currently > > > > + * set alpha2 by %NL80211_ATTR_REG_ALPHA2,. > > > > > > Please specify what command it comes in, probably _NEW_REG that you > > > haven't added. > > > > We can probably not even add this, what do you think? > > Well I think that some userspace programs like network manager want to > get a notification when for whatever reason the regdomain changes, and > they want to be able to query which one is currently set, and things > should be changeable. So you need at least three messages, NEW, GET, > SET, no? Then I see us requiring: SET and GET, but not NEW. If only need to "set" "one" regulatory domain, not create one and then set one. What do you think? > > > > CRDA replies by sending a regulatory domain > > > > + * structure which consists of %NL80211_ATTR_REG_ALPHA set to our current alpha2 > > > > + * if it found a match. > > > > > > Why set the alpha2 again? I thought the kernel queried for that? > > > > This is in case we wanted to support letting userspace query the kernel > > what alpha2 it has set. I'm OK with not supporting this though but it > > seemed it may have come in handy, hopefully not for abuse for other > > things. > > Yeah true, we may want to be able to force a certain regdomain. Huh? I was talking about querying from userspace to the kernel for the currently set alpha2, in case userspace may want to know what the kernel last used to ask CRDA for a regdomain. How did this change to being able to fore a certain regdomain? Anyway, the only valid case where I see us needing to set a regdomain manaullay is if an access point doesn't have an 802.11d country information element. Which BTW -- soon we'll have to decide how we want to implement, as we could either respect the IE with the channels passed or just ask CRDA for the alpha2 given. > > > > and a regulatory rule. The regulatory > > > > + * rule consists of set of frequency ranges given by > > > > + * %NL80211_ATTR_REG_RULE_FREQ_[START|END] with an attached power rule given > > > > + * by %NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN and > > > > + * %NL80211_ATTR_REG_RULE_POWER_MAX_EIRP. Each regulatory rule also has > > > > + * an attached %NL80211_ATTR_REG_RULE_FLAGS. > > > > > > How are these attributes used? Nested in some array? > > > > I wasn't sure yet, I wanted your feedback, but you are giving me this > > through IRC :) > > Well, as I said, look at how wiphy band info with frequencies works. > That's how you need to do it with netlink attributes. OK. > > > > + * @NL80211_ATTR_REG_RULE_FREQ_START: starting frequencry for the regulatory > > > > + * rule in KHz. This is not a center of frequency but an actual regulatory > > > ^^ remove > > > > + * band edge. > > > > + * @NL80211_ATTR_REG_RULE_FREQ_END: ending frequency for the regulatory rule > > > > + * in KHz. This is not a center a frequency but an actual regulatory > > > ^^ remove > > > > + * band edge. > > > > + * @NL80211_ATTR_REG_RULE_FREQ_MAX_BW: maximum allowed bandwidth for this > > > > + * frequency range, in KHz. > > > > + * @NL80211_ATTR_REG_RULE_POWER_MAX_ANT_GAIN: the maximum allowed antenna gain > > > > + * for a given frequency range. The value is in mBi (100 * dBi). > > > > > > Can be left out. > > > > OK. > > I mean, you have to add a note that it can be left out if it's not > specified in the db. N/A think right. Yeah sure, I'll update it. Which reminds me I have to hanlde that in reg.c, I didn't yet. > > > > @@ -9,137 +10,93 @@ > > > > */ > > > > > > > > /* > > > > - * This regulatory domain control implementation is highly incomplete, it > > > > - * only exists for the purpose of not regressing mac80211. > > > > - * > > > > - * For now, drivers can restrict the set of allowed channels by either > > > > - * not registering those channels or setting the IEEE80211_CHAN_DISABLED > > > > - * flag; that flag will only be *set* by this code, never *cleared. > > > > - * > > > > * The usual implementation is for a driver to read a device EEPROM to > > > > * determine which regulatory domain it should be operating under, then > > > > * looking up the allowable channels in a driver-local table and finally > > > > * registering those channels in the wiphy structure. > > > > * > > > > - * Alternatively, drivers that trust the regulatory domain control here > > > > - * will register a complete set of capabilities and the control code > > > > - * will restrict the set by setting the IEEE80211_CHAN_* flags. > > > > > > I think you shouldn't remove that but just rewrite it to make the driver > > > trust crda instead of this code. > > > > The EEPROM lets us get a list of supported channels for a product a > > customer (a vendor's customer, not a regular customer) decided to support. > > If we trust CRDA we then could potentially trust a different set of channels > > which the customer may not have tested his products on. They probably > > will work, but the safer approach is to support only the intended > > channels. > > > > We can then trust CRDA only to disable channels, not to *enable*. > > That's already covered by the paragraph above it though, "[t]he usual > implementation is for a driver [...]". Hence, you want to rewrite the > second paragraph as I mentioned :) OK. 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
