From: Dan Williams <dcbw@redhat.com>
To: Stuffed Crust <pizza@shaftnet.org>
Cc: Sam Leffler <sam@errno.com>, Jeff Garzik <jgarzik@pobox.com>,
Johannes Berg <johannes@sipsolutions.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: wireless: recap of current issues (configuration)
Date: Mon, 16 Jan 2006 13:39:58 -0500 [thread overview]
Message-ID: <1137436799.19714.5.camel@localhost.localdomain> (raw)
In-Reply-To: <20060116172817.GB8596@shaftnet.org>
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
next prev parent reply other threads:[~2006-01-16 18:39 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060113195723.GB16166@tuxdriver.com>
2006-01-13 21:26 ` wireless: recap of current issues (intro) John W. Linville
[not found] ` <20060113213011.GE16166@tuxdriver.com>
2006-01-13 22:19 ` wireless: recap of current issues (configuration) John W. Linville
2006-01-13 22:32 ` Johannes Berg
2006-01-14 1:17 ` Stuffed Crust
2006-01-14 9:28 ` Johannes Berg
2006-01-14 13:47 ` Krzysztof Halasa
2006-01-14 22:07 ` Jeff Garzik
2006-01-15 15:20 ` Stuffed Crust
2006-01-15 19:05 ` Samuel Ortiz
2006-01-16 17:09 ` Stuffed Crust
2006-01-16 18:51 ` Samuel Ortiz
2006-01-16 19:06 ` John W. Linville
2006-01-16 20:16 ` Samuel Ortiz
2006-01-16 21:06 ` Stuffed Crust
2006-01-16 22:24 ` Alan Cox
2006-01-16 23:02 ` John W. Linville
2006-01-17 18:41 ` Stuffed Crust
2006-01-17 18:54 ` Kyle Moffett
2006-01-15 19:53 ` Sam Leffler
2006-01-16 17:28 ` Stuffed Crust
2006-01-16 17:54 ` Sam Leffler
2006-01-16 19:40 ` Stuffed Crust
2006-01-16 20:14 ` Sam Leffler
2006-01-16 20:58 ` Stuffed Crust
2006-01-16 18:39 ` Dan Williams [this message]
2006-01-16 19:07 ` Samuel Ortiz
2006-01-16 19:50 ` Stuffed Crust
2006-01-16 20:10 ` Samuel Ortiz
2006-01-15 12:40 ` Stefan Rompf
2006-01-15 15:51 ` Johannes Berg
2006-01-15 17:53 ` Stefan Rompf
2006-01-15 20:08 ` Sam Leffler
2006-01-15 20:11 ` Johannes Berg
2006-01-17 22:20 ` Stefan Rompf
2006-01-15 19:39 ` Sam Leffler
2006-01-16 0:06 ` Mike Kershaw
2006-01-16 14:23 ` Jiri Benc
2006-01-16 14:55 ` Johannes Berg
2006-01-16 17:33 ` Stuffed Crust
2006-01-16 18:00 ` Sam Leffler
2006-01-16 20:16 ` Stuffed Crust
2006-01-14 0:05 ` Krzysztof Halasa
2006-01-14 23:41 ` Dan Williams
2006-01-15 16:18 ` Stuffed Crust
2006-01-15 9:35 ` feyd
[not found] ` <20060113213126.GF16166@tuxdriver.com>
2006-01-13 22:20 ` wireless: recap of current issues (compatibility) John W. Linville
2006-01-13 22:33 ` Johannes Berg
2006-01-14 13:44 ` Krzysztof Halasa
[not found] ` <20060113213200.GG16166@tuxdriver.com>
2006-01-13 22:22 ` wireless: recap of current issues (stack) John W. Linville
2006-01-13 22:34 ` Johannes Berg
2006-01-13 23:03 ` Chase Venters
2006-01-14 10:46 ` Simon Kelley
2006-01-14 23:29 ` Dan Williams
2006-01-14 13:51 ` Michael Buesch
2006-01-17 17:38 ` Jean Tourrilhes
2006-01-14 14:13 ` Ulrich Kunitz
2006-01-15 4:42 ` Pete Zaitcev
2006-01-15 10:04 ` Ulrich Kunitz
[not found] ` <20060113213237.GH16166@tuxdriver.com>
2006-01-13 22:24 ` wireless: recap of current issues (other issues) John W. Linville
2006-01-13 22:35 ` Johannes Berg
2006-01-13 23:02 ` Johannes Berg
2006-01-14 22:09 ` Jeff Garzik
2006-01-15 0:54 ` John W. Linville
2006-01-15 1:51 ` David S. Miller
2006-01-15 11:23 ` Arnaldo Carvalho de Melo
2006-01-15 15:39 ` Stuffed Crust
2006-01-17 23:36 ` wireless: recap of current issues (other issues / fake ethernet) Stefan Rompf
2006-01-18 16:32 ` Stuffed Crust
[not found] ` <20060113213311.GI16166@tuxdriver.com>
2006-01-13 22:25 ` wireless: recap of current issues (actions) John W. Linville
2006-01-13 22:36 ` Johannes Berg
2006-01-14 22:11 ` Jeff Garzik
2006-01-15 0:56 ` John W. Linville
2006-01-16 14:44 ` Johannes Berg
[not found] ` <43C80F9A.8020203@candelatech.com>
2006-01-13 22:49 ` wireless: recap of current issues Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1137436799.19714.5.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=jgarzik@pobox.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pizza@shaftnet.org \
--cc=sam@errno.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).