On Thu, 2006-04-13 at 08:12 -0400, Dan Williams wrote: > Maybe it's wrong now, but it's how the CLI tools have operated for quite > a while AFAIK.
Yes, and they don't seem to care about the netlink messages. But the question is rather -- should we block the program inside the kernel and only return from "get scan" after the scan is actually done, rather than returning "we can't give you anything now, try later". We could do that too, but then the program would be blocked inside the kernel without any chance of saying "bah, this takes too long, I'll ignore it". > There are two options for tools: (a) request scan and block on GIWSCAN > until it doesn't return EAGAIN, or (b) request a scan, enter a loop, > wait for the GIWSCAN netlink message to come back. The point here is > that if you have to write a tool with 100 lines of netlink message > processing code _just_ to get the "scan done!" message, that's a bitch. > More complicated programs can obviously do this, but simple tools don't > want or need to. Yeah, I just implemented that in softmac too (patch 5 of my set), so you can just request a scan and do nothing until you are notified that the netlink message came in that scanning is done. > airo, atmel, and orinoco all do this. ipw does not, and prism54 does > not because it does background scanning. I believe that the patch for > softmac/bcm43xx EAGAIN is correct. Good. I hope that these can go in before 2.6.17. johannes
signature.asc
Description: This is a digitally signed message part
