On Thu, Feb 5, 2009 at 4:57 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > 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. Good point. A simple token will resolve this problem but this is again changing wext which I wanted to avoid...no free lunch ( Anyhow I know it's possible but is this a common usecase that two application request scan? Thanks Tomas -- 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
