<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mike (mwester) wrote:
<blockquote cite="mid:48D26247.20303@dls.net" type="cite">
  <pre wrap="">Andy Green wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
:)  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.
  </pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:48D26247.20303@dls.net" type="cite">
  <pre wrap="">
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)

  </pre>
</blockquote>
<br>
</body>
</html>