On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote:
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in. Beyond that, the
> scanning smarts are all in the 802.11 stack. The driver should be as
> dumb as possible. :)
This is quite important... from a user perspective, it might be 2, 5, or
15 seconds before the card can actually scan all channels.
Unfortunately, background (passive) scanning by definition can't find
all access points, so you're going to need to do active scanning.
However, that active scanning should be controlled by userspace, not the
driver. Only userspace knows what policies the user him/herself has set
on powersaving mode.
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.
Scanning has the tradeoff of updated network list vs. saving power +
network disruption. The user, or programs delegated by the user, need
to make that choice, not the stack or the driver.
-------------
Furthermore, and this is also extremely important, user apps need to
know when the scan is done. From my look at drivers, _all_ cards know
when the hardware is in scanning states, and when its done. What many
don't do is communicate that information to userspace via wireless
events. The userspace app that requested scanning is then stuck
busy-waiting for the SIOCGIWSCAN to return success, which just sucks.
Much better if all drivers had the wireless event so that the userspace
app could just fire off the scan with SIOCSIWSCAN, and parse the results
when the event comes back rather than spinning.
In the netlink world, this would of course be done by multicasting the
"Scan Done" message to all interested clients, which would be just as
good.
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
