Re: State of the OpenMoko wlan driver

[Sean McNeil]

Mike (mwester) wrote: Andy Green wrote: -----BEGIN PGP SIGNED MESSAGE----- I proposed to push WLAN driver into modules a couple of weeks ago, here and on devel; it's something we need to do for a few reasons including being able to turn off WLAN better and have it recognized again when we turn it on. But it needs userspace world coordination, enhancing ifup and ifdown or whatever it is we use so they modprobe and modprobe -r, and control power through /sys. Nobody replied from userspace side. :) Probably because the userspace folks didn't take it seriously. If this was an automobile, it's like fixing a transmission problem by requiring that the user remove and reinstall the fuel-injectors each time they shift gears. And then arguing that this shouldn't be a big problem because it's easy to cut an access hole in the firewall so that the user doesn't have to stop the car while doing this. There are several really good reasons to make the wlan driver a module. Resource usage and security are the two biggest I can think of. I would have to agree, however, that using it for a last resort reset is probably not a good idea. We should be able to figure out what rmmod/insmod is doing that isn't being done in the case of ifdown/ifup. One big assumption here is that the userspace "ifup"/"ifdown" commands come from a single source base, and a further assumption is that "ifup"/"ifdown" is the only way the interface is manipulated. There are now many distros for the device (Qtopia, several OE-based distros, Debian, and more), and even in the core Om image (OE-based) we have the "ifup"/"ifdown" commands provided by busybox, the full version provided by the full utilities which can be "opkg" installed, then there's the ifconfig tools (which are still used by some), and frankly I have no idea what NetWorkManager and the various GUI-based autoconfig tools use. Beyond that, I really wonder what will happen if "ifup" (for example) pulls the module out and re-inserts it, if we don't start also patching - er, hacking up udev scripts -- could be some interesting things happening deep below the surface. We were also going to look at mdev as a faster udev at some point; if anyone wants to experiment with that they'll also need to accomodate any hackery required to ignore the appearance/disappearance of the i/f if it was "expected" because ifup/ifdown was already handling it. I think this one needs to be re-opened as a high-priority kernel problem. It seems likely that hackery will be required, but it would be preferable if that hackery was hidden inside the kernel rather than requiring the equivalent of access hatches cut into the engine compartment and a full set of wrenches and tools, just to be able to let the driver shift gears. Mike (mwester)