> > Module parameter, hard-coded filter, just to work around wext crap. Eww. > > NACK. > > we are perfectly aware that this is ugly and trust me, that nobody of us > wants to do it. However we do have these setups and they happen in real > life. I have been in a couple of locations where I ran into this problem > and in that cases there is no way for me to establish any kind of WiFi > connection at all, because the buffers are just too small. And that is > with a laptop. Then just think about a mobile phone running mac80211 > where the memory is limited. That's a straw-man. Your applications are _artificially_ limiting the wext buffer size, to something well below your mobile phone's memory. > So WEXT is crap and everybody agrees, but until we can use cfg80211 for > scanning, we need something to make this work. So if this patch is not > acceptable, then do we get scanning support via cfg80211 for 2.6.30? You > were always marking your patches as development/RFC. This patch is _certainly_ not acceptable. You know that just as well as I do. And of course you can get scanning with cfg80211/nl80211 in 2.6.30. You just have to help make it work. The patch below has one major flaw: it keeps all BSSes in a doubly-linked list. That gives horrible lookup behaviour. So I set about to fix it: http://johannes.sipsolutions.net/patches/kernel/all/LATEST/029-b%2btree.patch http://johannes.sipsolutions.net/patches/kernel/all/LATEST/030-cfg80211-scan-btree.patch but the b+tree was pretty much rejected, and I don't currently have time to spend on investigating other types of trees (rbtrees, ...) or hash tables. Without that, it's going to suck, especially on the embedded devices you mention. > > Go for > > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/028-cfg80211-scan.patch > > Return a 404 btw. Yeah, so I rebased and it's now at http://johannes.sipsolutions.net/patches/kernel/all/LATEST/024-cfg80211-scan.patch johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
