On Fri, 2009-05-15 at 23:12 -0700, Luis R. Rodriguez wrote: > > I think this is a good idea, although it wouldn't solve anything for > > people stuck on old userspace (my oldest target is distributions > > releases circa 2.6.27). Not sure what is best for that case. The > > kernel could be informed of the lack of userspace regulating this and > > then take some reasonable action. What the reasonable action and the > > terms for that remain unclear to me. > > OK so what if we just let let old wext scan be just a dump of the > current bss list provided we do selective scanning once per channel > throughout a period of time. Hmm, no. I don't think we want to scan automatically. On the other hand, a scan that the user triggered could be spread out over more time like I just wrote in the other mail. > For new userspace can obviously do whatever we like but since we'd > implement the above we could just let this automatic scanning can be > tweaked for roaming purpose with exposed knobs. That is -- make the > code so that it can be tweaked to act like a regular good old scan or > take breaks throughout. > > If you're already associated it makes little sense to be scanning all > over. If you're not associated it makes sense to do the good old scan > we're used to. Of course this would just be fof mac80211 and cfg80211 > drivers, old wext will obviously still behave the same for old > hardware. Ick. [other mail] > Additionally we could add Kconfig for SMART_WEXT or whatever, and old > configs would behave the same. However users of old distributions > wanting new shiny drivers with new shiny benefits can enable it -- and > it would still work with old userspace. How complicated do you want to make it? No, I just think we should, if associated, spread out the scan a little more, and not change anything in the userspace API at all, just change the time it takes to do the scan and allow data to pass by going back to the operational channel. Now, I'm not saying this is easy, it can be almost arbitrarily tricky, but I still think we should do it. One thing for example could be if we're scanning the operational channel then the only thing we do is send probe requests, nothing more. The other thing to notice is that there's a race between RX and channel switch that I pointed out before -- and not all hardware is capable of closing that race. Atheros hardware for example doesn't seem to contain the channel the frame was received on in the RX information, so that the driver fills that in based on the current operating channel, which means that in order to report that correctly you have to flush RX... Then again I don't quite see why we discard frames received during a scan even if they were for us. Anyway, bottom line is that I don't think we should change the APIs in any way, we should instead make the scan smarter by spreading it out if we're active. This even applies to scanning while in an IBSS -- stop beaconing, then go scan etc. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
