On Fri, 2011-05-13 at 12:52 +0200, Johannes Berg wrote: > On Fri, 2011-05-13 at 12:45 +0200, Stanislaw Gruszka wrote: > > > > because the scheduled scan is a long-term operation and the normal scan > > > is done for a very short time (and the rest of the stack assumes it will > > > complete quickly enough as not to interfere with the connection. > > > > Hmm, is this drawback of implementation or can not be done technically > > (question to myself :-) ? I can image that in ideal case hardware scanning > > will not affect normal operation, no matter how long it will take. > > Software scan is much worse, since we have to change channels manually. > > We currently share code between software scan and hardware scan in > > mac80211. Perhaps separating hw and sw scan code, would be a good idea > > and allow to consolidate hw scan and sched scan. I planning to look > > at this more closely. > > Well, it's also a semantic question. If you trigger a scan, you expect a > result (or an abort) after a while. It could of course be extended with > a new attribute, but the error checking for that gets complicated, > especially if you consider older kernels that would simply ignore that > new attribute. > > So basically, the only difference between "trigger scan (scheduled=1)" > and "trigger scheduled scan" (which this implements) would be in > nl80211. Everything else would have to separate them, since there are a > lot of internal things that behave differently depending on whether a > scan is running or not. Add the error checking, and I think we've got a > good case for new API :) I agree. I think it's better to keep it simpler with a new command. Especially because the scheduled scan command will be extended with a few more arguments, which may not make sense with normal scans, such as filters etc. -- Cheers, Luca. -- 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
