[RFC 0/1] libertas: new scan logic

[Dan Williams]

On Thu, 2007-11-29 at 09:46 +0100, Holger Schurig wrote:
> > 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.

Well, in this case I meant decouple the idea of SIOCSIWSCAN ioctl call
from the GIWSCAN WEXT event.

> > 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 

My point before was dependent about _not_ returning EAGAIN, sorry if I
didn't make that clear.  There's two choices, either (a) return EAGAIN,
or (b) return the BSS list every time and send events.  (a) works with
iwlist, (b) works better for longer-lived tools.  But you're correct
that using EAGAIN would have no effect on longer-lived tools if the
GIWSCAN events only get delivered at scan completion (ie, without
background scanning).

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

Right; except that in the docs I've read (5.1 spec especially), the
firmware can only background scan during deep sleep, apparently.

Dan