Re: [PATCH 01/19] orinoco: Add ESSID specific scanning for Agere fw

[Dan Williams <dcbw@redhat.com>]

On Tue, 2008-08-05 at 18:48 -0400, Pavel Roskin wrote:
> On Tue, 2008-08-05 at 17:55 -0400, Dan Williams wrote:
> > On Tue, 2008-08-05 at 17:15 -0400, Pavel Roskin wrote:
> 
> > > If I use 32-bit kernel with 32-bit userspace, essid filtering works, but
> > > only to a degree.  Old scan results are cached somewhere, so if I scan
> > > with essid and then without essid, I get filtered results.  Likewise, If
> > > I don't use filtering the first time, but use it the second time, I get
> > > unfiltered results.
> > 
> > Scanning for a specific SSID never has "filtered" the results, nor
> > should it.  It just probe-scans the requested SSID and return any new
> > results in with the cached ones.  You requested an SSID scan, thus you
> > must know the SSID, thus you can do the filtering yourself?
> 
> Perhaps I used a wrong word.  If requesting a scan, I expect to get
> results from a scan with the parameters I supplied.  If the scan results
> are from a scan with different parameters, I don't want them.  I'd
> rather see the driver return EAGAIN than results of a scan with
> different parameters.

I'm not quite sure what you mean here.  You mean to say that if you
request a specific SSID scan, and the driver does not find that SSID,
that it should return EAGAIN?  I think that would be overloading EAGAIN
too much, since for scans EAGAIN means "I'm not done with your scan
request yet".

> The userspace is welcome to keep a pool of all APs found by any scans,
> but I don't think drivers should do it.

Drivers need to keep a reasonably complete list of APs internally for
association anyway.  You don't want to have to do a full scan just to
associate if you have results from 10 seconds ago that are still valid.
Furthermore, drivers need to keep cached results so that two processes
can request results of a scan after the scan is complete.  The previous
situation where the driver would clear the scan list whenever GIWSCAN
was called just sucked because then two processes would race for the
results after an IWSCAN event and one would get nothing.

A scan is a global result, not a result specific to the request.  Thus,
since any process can read the results, and since only one process is
privy to the details of how the scan was performed with WEXT, you have
to return a complete list of results for each call to GIWSCAN.

Honestly, I don't think it's that much of a problem for the userspace
process that actually requested the scan to keep it's scan parameters
around and filter the results that come back using those parameters.

Dan