On Sat, Feb 21, 2009 at 7:31 AM, Gábor Stefanik <netrolller.3d@xxxxxxxxx> wrote: > On Sat, Feb 21, 2009 at 12:40 AM, Luis R. Rodriguez > <mcgrof@xxxxxxxxxxxxxxxxxxxxxx> wrote: >> On Fri, Feb 20, 2009 at 10:07:05PM +0100, Gábor Stefanik wrote: >>> On Fri, Feb 20, 2009 at 9:33 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: >>> > On Fri, Feb 20, 2009 at 11:45 AM, Gábor Stefanik >>> > <netrolller.3d@xxxxxxxxx> wrote: >>> >> On Wed, Feb 18, 2009 at 11:48 PM, Luis R. Rodriguez >>> >> <mcgrof@xxxxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> On Wed, Feb 18, 2009 at 04:38:10PM -0600, Larry Finger wrote: >>> >>>> Luis R. Rodriguez wrote: >>> >>>> > On Wed, Feb 18, 2009 at 01:31:52PM -0800, Johannes Berg wrote: >>> >>>> >> On Wed, 2009-02-18 at 15:29 -0600, Larry Finger wrote: >>> >>>> >>> On at least one forum, I have seen the recommendation that a user set their >>> >>>> >>> regulatory domain by creating the file /etc/modprobe.d/cfg80211 with the >>> >>>> >>> contents "ieee80211_regdom=US". >>> >>>> >>> >>> >>>> >>> That works as long as CONFIG_WIRELESS_OLD_REGULATORY is set in their .config, >>> >>>> >>> but will fail if it is not. >>> >>>> >>> >>> >>>> >>> Should the module_param statement be moved outside the ifdef >>> >>>> >>> CONFIG_WIRELESS_OLD...? Setting the module parameter that way might not make any >>> >>>> >>> sense, but it surely shouldn't kill wireless. >>> >>>> >> I actually see no reason to not just /honour/ it by calling crda with >>> >>>> >> its parameter if CONFIG_WIRELESS_OLD_REGULATORY isn't set. >>> >>>> > >>> >>>> > The idea was that things we want to get rid of will go in OLD_REG. Static regdoms >>> >>>> > for US, JP and EU fall into that and so does the module parameter. I believe >>> >>>> > it is silly to keep the module parameter around as we already have userspace >>> >>>> > APIs to let users set this. >>> >>>> >>> >>>> I guess we leave it the way it is. At least the only people that will get caught >>> >>>> are those that upgrade their distro. >>> >>> >>> >>> Yeah, if they disable OLD_REG -- but I am curious which distributions are using this >>> >>> themselves as well. Would you happen to know ? Or are you mostly seeing just users >>> >>> doing that themselves? >>> >> >>> >> Yes, I was talking about users doing this, users who upgrade their >>> >> kernel without upgrading their distro. Keeping a modparam provides an >>> >> easy way for users to upgrade kernels without a full distro upgrade - >>> >> modparams have a much simpler syntax than init scripts. If we keep the >>> >> modparam as a way to control CRDA, this is what an user has to do to >>> >> upgrade: >>> >> 1. Compile and install the new kernel. (Mostly straightforward, as >>> >> long as the user has a config and knows how to use make.) >>> >> 2. Compile and install CRDA. (Straightforward.) >>> >> 3. echo options cfg80211 ieee80211_regdom="HU" >> >>> >> /etc/modprobe.d/options (Straightforward.) >>> >> >>> >> Removing the modparam changes step 3 to: >>> >> 3. Find the init scripts, and edit them to include "iw reg set HU", >>> >> making sure it happens early enough, caring about the syntax, taking >>> >> into account differences between distros, etc. Possibly includes >>> >> modifying the initramfs/initrd by hand in some odd distros. (Not >>> >> straightforward at all, requires knowledge of the distro's inner >>> >> workings, such as the init version used, e.g. sysvinit, bsdinit, >>> >> upstart, etc.) >>> > >>> > It seems reasonable to keep the module parameter in case iw is not >>> > installed but if users went through the trouble of installing crda are >>> > we to not expect users to have iw also by 2.6.30? >>> > >>> > Luis >>> > >>> >>> I am not talking about the case when iw is not installed - even if iw >>> is installed, it is much easier to edit the module options file than >>> the init scripts. >> >> We should strive away from using module parameters and provided we have >> a good userspace API it should be up to userspace to figure that stuff out. >> >> Although an ieee80211_regdom module parameter may be convenient its not >> productive towards what we want as well -- we shouldn't strive to let your >> module parameter be the only place to put your location information from >> userspace. Say you suspend to ram, fly to another country -- you'd want >> more of an intelligent usersapce figuring out your location for you and you >> don't want it to muck with your module parameters. >> >> Luis >> > > In my proposal, the userspace can still override the regdom set in the > modparam - it is only for setting the initial regdomain. So, you > suspend to ram, fly to another country, resume and if you have the > right utilities installed, userspace will reconfigure your regdomain > to match the current place. However, it is up to distributors to > include such utilities, it is quite hard for users to install them > from sources > Distributors can also easily include the necessary CRDA command in > their init scripts, but I am not talking about new distributions, but > rather users who upgrade their kernel. Removing the modparam would > amount to requiring users to either upgrade their distro or be > absolutely confident editing all types of init scripts (be it > sysvinit, bsdinit, upstart or some other apocryphal init program) to > get a proper initial regdomain. (In fact, due to the lack of such > modparam support, right now I am always doing "iw reg set HU" by hand > on every boot, as I can't figure out how to properly edit the init > scripts without YaST corrupting them upon the next system update!) > New distros can do fancy userspace tricks like setting the regdomain > based on GPS position, but for users of old distros who upgraded their > kernel/installed compat-wireless, the choice is to either use only the > world regdomain channels (bad) or set regdomain by hand on every boot > (inconvenient). > > So, here is a more "visual" approach to the proposal (in all of these > examples, iw and crda are installed): > > Case 1: Compat-wireless installed on e.g. Ubuntu Intrepid, in Israel > 1. System boots up. Cfg80211 from newly installed compat-wireless (and > NOT the one shipped by the distro) loads with regdom=IL. > --- The regdomain is now Israel. Channels 12 and 13 are available. --- > 2. During the init process, network startup is reached. The system > auto-connects to ESSID "MyNET123", which is on channel 13. IP address > assigned via DHCP. > 3. When X starts up, the system is ready for the user to browse the web. > > Case 2: Same system if modparam support is removed > 1. System boots up. Cfg80211 of compat-wireless loads. Initial > regdomain is hardcoded to World. > --- The regdomain is World. Only b/g channels 1-11 are available. --- > 2. Network startup is reached. Auto-connect impossible, as channel 13 > is disabled. > 3. X starts up, but no networking - the user must "iw reg set IL" and > connect by hand, requiring root access. > > Case 3: Fedora 11 (with support for setting regdomain based on GPS - I > hope it will!), in Germany (the user iften roams throughout Europe) > 1. System boots up. Cfg80211 of the distro loads with regdom=EU. > --- The regdomain is now EU. --- > 2. The GPS device is initialized. > 3. Upon network startup, location is identified as Darmstadt > University, Germany, so "iw reg set DE" is called. > --- The regdomain is now DE, which is correct. --- > 4. Network startup continues, auto-connect to ESSID "Universität" successful. > 5. Upon X startup, wireless is up with regdom=DE. > 6. User files to Denmark. Regdomain changes to DK. > > Case 4: Same system without modparam support: > 1. System boots up. Cfg80211 of the distro loads with hardcoded "World". > --- The regdomain is now World. --- > 2. The GPS device is initialized. > 3. Upon network startup, location is identified as Darmstadt > University, Germany, so "iw reg set DE" is called. > --- The regdomain is now DE, which is correct. --- > 4. Network startup continues, auto-connect to ESSID "Universität" successful. > 5. Upon X startup, wireless is up with regdom=DE. > 6. User files to Denmark. Regdomain changes to DK. > > So, cases 3 and 4 (new, regdomain-aware distro) are equivalent from > the user's standpoint - but case 1 (old, regdomain-unaware distro with > compat-wireless adding "aftermarket" CRDA support) is much better than > case 2. If we enable passive scan on channels 12-14 on the world regdomain (which it seems we should) that would cure this issue as well. Thoughts? 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
