> Yes; a scan list is a system resource, not per-process of > course; the driver should be adding the new results to it's > internal scan cache and timing out old results as appropriate. Agreed. > That said, it would be useful to pass the requested scan > options along with the "scan completed" response. Say process > A just scans "ch1 + ssid foo", and process B wants full scans. > If process B just listens for scan events, and backs off a > scan timer each time an event comes in, it'll never ever get > any results other than what process A requested. If scan > options were passed along with the "scan completed" event, > then process B could figure out that it needs more complete > scan information and trigger a scan by itself. Right now with > WEXT, we can't do this AFAIK. That's one possible solution, but if I get you correctly, then the kernel would need to keep a FIFO of the various scan requests. However, scanning is something that is restricted by the hardware. We just define that "There can only be one scan in progress per time per hardware". So if the hardware is busy, we can return an error. The client than knows that he has to request the same scan later (ideally probably after a "scan done" event has been seen). Process A Process B mac80211 / Hardware "do scan MUH" - scan for MUH on channel 1 - - scan for MUH on channel 2 - - ... - - scan for MUH on channel 12 - "scan BLAH" -> -EAGAIN scan for MUH on channel 13 - - "scan done" notification "get result" "do scan BLAH" scan for BLAH on channel 1 - - ... So, if you do a "scan MUH" and you don't get an -EAGAIN, the next "scan done" event is yours and you get "your" scan result with "get result". If you get an -EAGAIN, you cannot scan until the current scan is done. This is marked by the next "scan done" event. You can then decide to get the other process' scan result and do something with it --- or you can issue your own "do scan" command and wait until you get your "scan done". I think this is both efficient and flexible. -- 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
