From: Michael Buesch <mb@bu3sch.de>
To: "Simon Barber" <simon@devicescape.com>
Cc: netdev@vger.kernel.org, "Jean Tourrilhes" <jt@hpl.hp.com>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Dan Williams" <dcbw@redhat.com>
Subject: Re: proposal for new wireless configuration API
Date: Tue, 15 Aug 2006 21:35:53 +0200 [thread overview]
Message-ID: <200608152135.54238.mb@bu3sch.de> (raw)
In-Reply-To: <C86180A8C204554D8A3323D8F6B0A29F0165AE04@dhost002-46.dex002.intermedia.net>
On Tuesday 15 August 2006 21:27, Simon Barber wrote:
> A further complication happens in Japan with 802.11j, and now in the USA
> too - with 802.11y in the 3.65Ghz band - here there are some new channel
> widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
> OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can
> run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter
> rate, giving a 5Mhz wide channel. Hence same frequency, different
> channel spec. Using a channel number is the way to go. If we need
> something to convert between the 2 it should probably be a library in
> user space (in hostapd or wpa_supplicant) - hostapd does have this
> today.
>
> It might be nice if other applications could access this data too - but
> I don't think it needs to be inside the kernel.
We need this conversion function, as most devices tune to frequencies,
not channels. So when a driver is instructed to tune to channel 2,
it must call back into the 80211 stack to ask for the frequency (based
on the current PHYMODE and the other parameters you mentioned above).
That call should IMO not result in a call to userspace. Userspace
should instead set flags _before_ in the stack and the conversion
callback would act on these flags.
That way userspace only has to tell the kernel once which frequency-band,
half, quater freq, or whatever it wants. The actual conversion
from channel number to freq (or the other way around) is trivial after
that, as it's only a few ifs and elses based on some cheap flags.
--
Greetings Michael.
next prev parent reply other threads:[~2006-08-15 19:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 15:28 proposal for new wireless configuration API Johannes Berg
2006-08-15 16:14 ` Luis R. Rodriguez
2006-08-16 7:26 ` Johannes Berg
2006-08-15 16:29 ` Dan Williams
2006-08-15 16:38 ` Michael Buesch
2006-08-15 18:14 ` Dan Williams
2006-08-15 19:13 ` Michael Buesch
2006-08-15 19:27 ` Simon Barber
2006-08-15 19:35 ` Michael Buesch [this message]
2006-08-15 20:06 ` Dan Williams
2006-08-15 19:59 ` Dan Williams
2006-08-16 7:14 ` Johannes Berg
2006-08-17 19:39 ` Jean Tourrilhes
2006-08-17 21:24 ` Michael Buesch
2006-08-17 23:29 ` Ulrich Kunitz
2006-08-18 7:12 ` Johannes Berg
2006-08-18 15:00 ` John W. Linville
2006-08-18 21:29 ` Ulrich Kunitz
2006-08-18 22:02 ` Michael Buesch
2006-08-21 7:31 ` Johannes Berg
2006-08-16 6:51 ` Johannes Berg
2006-08-16 18:02 ` Simon Barber
2006-08-17 7:19 ` Johannes Berg
2006-08-17 16:42 ` Simon Barber
2006-08-17 23:23 ` Ulrich Kunitz
2006-08-18 7:01 ` Johannes Berg
2006-08-18 16:45 ` Simon Barber
2006-08-21 6:45 ` Johannes Berg
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=200608152135.54238.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=dcbw@redhat.com \
--cc=johannes@sipsolutions.net \
--cc=jt@hpl.hp.com \
--cc=netdev@vger.kernel.org \
--cc=simon@devicescape.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).