On Thu, 2009-02-05 at 15:00 +0200, Tomas Winkler wrote: > On Thu, Feb 5, 2009 at 2:12 PM, Jouni Malinen <j@xxxxx> wrote: > > On Thu, Feb 05, 2009 at 01:44:15PM +0200, Tomas Winkler wrote: > > > >> Just a thought If user space will be able to merge 2 scan results we > >> can then split then in 2 separate reports.... > > > > Theoretically speaking, yes, WEXT could be extended to do this with some > > kind of scan parameter that indicates which 64 kB block is requested. > > However, I would not suggest going there and I would probably object to > > a patch that tries to do this either in the kernel or in wpa_supplicant > > for that matter. > > I thin it can be done w/o extension of wext, j ust the eviction of > old scan results is done > in user space.IRCC the time stamp of beacon/probe is part of each > entry. And user space state machine should be able to react on > nl[SIOCGIWSCAN] w/o issuing ioctl[SIOCSIWSCAN]: I still don't like this. If 177 BSSes is not enough, then get the cfg80211 stuff working better for you. I can't think of how this scheme would work; which half of the results get returned when something calls SIOCGIWSCAN? Would the driver/stack internally flip to the other half of the results on each call of SIOCGIWSCAN? That doesn't work, because then two userspace processes requesting scan results will race with each other for them. We had this problem before when drivers cleared the scan list each time SIOCGIWSCAN was called. Dan > > If you really end up hitting a case that does not work reasonably well > > with 64 kB fix in user space, I would suggest looking into the > > cfg80211/nl80211 scan stuff. The only additional thing it needs in such > > an environment is to get better optimized data structure (for which, > > there is already a proposed implementation, too). > > Guess we need to proceed with cfg anyway > > Tomas > > > -- > > Jouni Malinen PGP id EFC895FA > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
