On Thu, Sep 01, 2005 at 07:36:34PM +0100, Pedro Ramalhais wrote:
>
> Oops, my brain had censored that part of the iwconfig manual.
Yeah, it come at the end of a long page ;-)
> Reading that, and since i imagine that few people use it,
Not explicitely, but it's used internally.
> it comes to
> mind that we could abuse this, and redefine it to be THE association
> command.
As stated earlier, the problem is *NOT* specific to wireless
(some USB-Ethernet or Firewire adapters may need to load firmware), so
I believe the solution should not be wireless specific (i.e. DHCP
should wait for the link up event, card could be identified by
businfo).
> ex:
> iwconfig eth0 commit would cause association and no other command would
> cause it.
The current expected behavior is that if commit has not been
done at "ifconfig up" time, it should be done then by the driver. I
would keep that, it's a sane behavior that make sure the system behave
in expected way if the user/scripts do stupid things.
One change that could be done is to have the commit handler
called explicitely by the kernel when the user do "ifconfig up",
instead of the current implicit behavior. I did not do that because I
did not want to change generic Ethernet code, but now that we have our
own device type, it may make sense.
> I also fail to see what other uses it could have besides setting the
> configuration on the card all at once.
Well, it was designed explicitely for that ;-)
> Which wireless settings could be
> left to be applied on the card "later"?
Manual override. At any point in time, even if the card is up,
the user/tools can use ifconfig to change the IP address and ethtool
to change the Ethernet media (speed/duplex). I don't see any reason of
getting rid of that (and the commit stuff behave sanely in this case).
Only a single driver doesn't allow manual override of wireless
params, ray_cs, and I don't want this list to grow. Otherwise, we
might as well just use module parameters and be done with it...
> hmmm, the only thing coming to
> mind is waiting for a scan to finish, does that count? That would be
> better exposed as a BLOCKING vs NONBLOCKING setting.
The scan API is quite different from the other APIs for this
specific reason (trigger cmd + event + read cmd). It's usually easier
to emulate a blocking behaviour from a non-blocking API than vice
versa, so I would not want the scanning API to be blocking.
> Thanks!
> --
> Pedro Ramalhais <[EMAIL PROTECTED]>
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
