State of the OpenMoko wlan driver

[Mike (mwester)]

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.

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)