Messages in this thread | | | Date | Thu, 09 Jun 2005 21:46:27 -0500 | From | Alejandro Bonilla <> | Subject | Re: ipw2100: firmware problem |
| |
Jeff Garzik wrote:
> James Ketrenos wrote: > >> I don't know if all the distributions have moved away from this >> model. If they have and the devices are brought up regardless of >> link, then >> going back to delaying radio initialization until the open() is called >> is workable. > > > > When the interface is not up, we ideally want the device to be as > passive as possible. > > Most net drivers shut down as much as possible at dev->close() time, > and it would really be good if wireless drivers followed suit. > > Jeff > > > OK. I understand the point and I totally agree with this. We really want the adapter to just do what the user or profiles ask the adapter to do. Yes, in an ideal world.
Let's talk about easyness. These adapters are in laptops. You don't want to type a lot of stop everytime you move from access points, reboots and so on. In a server enviroment with the ethernet adapters, we really just want them to do what they do and we have scripts for it. So, again, with mobile is different. An association on boot is fair and really OK. You are not really doing dhcp requests on boot and trying to get the internet from people for free. You just want you adapter running faster, get connected and get over whatever you have to do to start working or whatsoever.
Let's really think what would be the nicest way that the card should behave, after all if the adapter just associates, you are not really stealing any Internet. :)
Association on boot is how it has worked all the time, and in the 18 months of the project, nobody has complained about it... So... I wonder, users are happy with it? (I know it might not be the correct way)
Just a thought.
.Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |