Subject: Re: proposal for new wireless configuration API

From: Michael Buesch <[email-masked]>
Date: Tue, 15 Aug 2006 21:13:23 +0200

On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> 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 channel<->freq mapping is stable.
What is unstable is the allowed channels map.
For APHY there are even many gaps in the map. For example
channels 6, 40 and 55 may be the only ones allowed

(6, 40, 55 are generated by my /brain/random device ;) )

The frequency range you mention is selected differently by
another config option. In d80211 we call it the PHYMODE.
Switching the PHYMODE changes the meaning of channel values
and changes the output of the two functions below.

So if I want to switch to channel 4 in the 2.4Ghz band, I would do:
select PHYMODE B or G,
select channel 4.

That would lead to the card tuning to 2427 MHz.

> > 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.

Hm, I don't know if I understand this correctly.
You want to implement the mapping function in every driver
or in the d80211 stack?
It belongs into a central place in the 80211 stack. There where
regulatory domain stuff is managed, too.

We need functions like:

u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel);
u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel);

These would be used in drivers to convert values.
The validity of the channel value passed from userspace would be
checked in the _stack_. If the user passes an illegal value for
his country, it would never reach the driver.

-- 
Greetings Michael.