From: Dan Williams <dcbw@redhat.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: netdev@vger.kernel.org, Jean Tourrilhes <jt@hpl.hp.com>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: proposal for new wireless configuration API
Date: Tue, 15 Aug 2006 14:14:48 -0400 [thread overview]
Message-ID: <1155665688.8940.10.camel@localhost.localdomain> (raw)
In-Reply-To: <200608151838.58182.mb@bu3sch.de>
On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > o Separate attributes for channel and frequency
>
> No, channel and freq is the same. It's just another name
> for the same child. I would say we only want to deal with channel numbers
> in the API. That's much easier, as we don't have to deal with this
> fixed-point (or even floating point) mess. Look at WE for the
> fixed-point mess.
Right, I don't have a problem with only using one or the other; but we
_HAVE_ to provide a function in the driver that allows userspace
programs to convert channel <-> frequency both ways, like you suggest
below. Obviously the channel/frequency mapping isn't the same
everywhere.
[ or is it? I'd be very uncomfortable using the same channel #s
everywhere unless some IEEE spec states exactly what the channel #s are
for every frequency range that wireless stuff operates in ]
> The userspace tools can easily convert freq to channel and back.
> And in the kernel, we can easily provide some small function
> to convert from channel to khz and back, for example. But I would
> like to see the fixed-point stuff in the API vanish.
No argument here; as long as we provide the mapping function in the
driver for each card.
> > o Method of finding out channel <-> frequency mapping (not all drivers
> > support this in the SIOCGIWRANGE handler now)
>
> Yes, that would be a good idea.
> Comes next to the conversion function (see above).
Yep.
Dan
next prev parent reply other threads:[~2006-08-15 18:15 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 [this message]
2006-08-15 19:13 ` Michael Buesch
2006-08-15 19:27 ` Simon Barber
2006-08-15 19:35 ` Michael Buesch
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=1155665688.8940.10.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=johannes@sipsolutions.net \
--cc=jt@hpl.hp.com \
--cc=mb@bu3sch.de \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.