[RFC 0/1] libertas: new scan logic

[Holger Schurig]

> If you want to make get_scan wait until you actually have scan
> results, then you make get_scan return EAGAIN while a scan is
> in-flight until you have the new results.

Thanks, this was the piece that was missing. With that info, I 
was able to remove all of my TODO items.

After you told me this, I found the equivalent piece in 
net/mac80211/ieee80211_ioctl.c, function 
ieee80211_ioctl_giwscan():

       if (local->sta_scanning)
                return -EAGAIN;

I'm now doing something similar in the new scan.c (I'm just have 
adapter->last_scanned_channel != 0 as a "flag" to denote scan in 
progress or not).


> Doesn't matter; decouple the idea of GIWSCAN from SIWSCAN.

Okay, you're right. Any application is free to send ten SIWSCAN 
ioctls and then 5 GIWSCAN ioctls ones.

> You should send a GIWSCAN event whenever you get new BSS
> information.  For example, if the card does background
> scanning, even if just on the associated channel (like ipw
> cards do), then you need to send a GIWSCAN event for each time
> the BSS list changes.  They are not explicitly tied together.
> Tools like iwlist don't even care about events, so they don't
> matter here.  Moreover, your app could get a GIWSCAN because
> some other app triggered a scan.  Two apps can trigger
> successive scans too, and you'll only get one GIWSCAN event at
> the end of it anyway.  There is not a 1:1 relationship between
> a SIWSCAN request and GIWSCAN event.

While your whole idea about user-space tools that support partial 
scan results is interesting, it wouldn't work the way you're 
describing it.

Suppose I'm in a scan. And whenever I get info for APs, I send a 
GIWSCAN event out. So for scanning 13 b/g channels I maybe send 
4 wireless events. That's ok for iwlist, and any tool that 
doesn't care for wireless-events.

But your tool that uses this event and an internal BSS list 
wouldn't have any advantage. It would receive the GIWSCAN event, 
it would know that now there is info about some more BSSs. But 
it would not be able to access the data about this new BSSs, 
because the GIWSCAN ioctl would just return -EAGAIN until the 
scan has finished. So it wouldn't be able to update it's local 
list of APs and the extra GIWSCAN event's wouldn't be useless.

So sending one GIWSCAN event when user-space actually can access 
the data makes more sense.




Adding adding background-scanning and then re-examining your idea 
would be the job of a later patch.