On Sat, 27 Aug 2005 11:21:37 -0500, James Ketrenos wrote:
> The order required of user space is:
> 
>    kernel                         hotplug               hotplug script
>    -----------------------        --------------        -----------
> 1. module load
> 2. netdev device registered
> 3.                                new device
> 4.                                                      ifconfig up
> 5. open: load firmware,
> 6. init device, etc.
> 7.                                                      configure wireless
> 8. scan
> 9. associate
> A.
> link                                                                          
>           
> 
> B.                                                      carrier detected
> C.                                                      configure link
> (dhcp)

I don't agree with this scheme. Association should be started on
explicit userspace request (*). As we definitely don't want to add a new
WE (or some other) call to perform this, the only call we can use for
telling the driver "ok, now it's the time to associate" is ifconfig up.
So opening the card should follow its configuration.

And yes, this brings up the problem with firmware loading. It should
really be solved, but trying to solve it by requiring to bring the card
up before it is configured is the bad way.

Today, some cards require to be brought up before they are configured
and some require it in the other order. Distributions have to deal with
it if they want to support different devices. It definitely needs to be
unified. And when the unification is performed, why not do this the
right way?

(*) Because it's not good idea to start association before wireless is
fully configured. Trying to associate to some random AP because
semi-entered configuration matches the AP settings is very unexpected
behaviour. And there might arise some problems with allowed/forbidden
channels as well.

-- 
Jiri Benc
SUSE Labs
-
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

Reply via email to