I had an argument with David a few month ago on the subject
(you can ask him how it ended). I believe that it's not a good
practice to "schedule" in any of the ioctl, and that seem to also
apply to get_wireless_stats. On the other hand, you can perfectly take
a spinlock, disable irq and do your job.
For the ioctl, on the way down you grab the rtnetlink
semaphore, which mean that all ioctl and rtnetlink operation will be
blocked until you return. That's the reason I deprecated the old
APLIST ioctl and designed the SCAN support as a *pair* of ioctl (+ an
event).
For get_wireless_stats, check what I did in Orinoco. I
basically get (under spinlock) the stuff I can get immediately (RSSI),
start a request for the counters and return the result of the
*previous* request. That's the best I can think, because I don't want
to run permanently a thread that poll the counters and this way the
counter polling rate is adapted to what the user so.
Note that in your case, the issue is slightly different. I
believe that the probability of having the BAD busy is not that
high. In that case, just return the last polled value, and set the
updated flag to 0 (now you understand why there is an updated flag).
> Jouni Malinen PGP id EFC895FA
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/