On Tue, 2006-08-15 at 21:13 +0200, Michael Buesch wrote: > 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.
Ok, so if somebody magically opens up new unlicensed ISM spectrum around, say, 7GHz, does that space get broken into channels and assigned specific numbers by the IEEE? I know there are stable channel #s for abg range. What about the future? [1] Can we guarantee that whenever new spectrum opens up that future 802.11 products may use, that the mappings are well-defined? That was my main question. > 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. That sounds fine to me. > > > 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? If we can assume that future spectrum will have well-defined channel numbers, then I don't have a problem with having the mapping function _once_ in d80211. Will the d80211 stack _only_ be used for 802.11 [a|b|g|n] implementations? What if another implementation comes around that uses a different PHY but the same spectrum and same protocol? Ultrawide Band using 802.11 protocol or something? Who knows? > It belongs into a central place in the 80211 stack. There where > regulatory domain stuff is managed, too. No argument there. I'm just wondering aloud if we can guarantee that the mappings will always be the same for stuff other than 802.11[abgn]. Originally, Linux Wireless Extensions was designed with stuff in addition to 802.11. It happened that 802.11 is pretty much the only thing that uses WE. Since d80211 is by nature an _802.11_ stack, it's fine to restrict the configuration to 802.11 stuff. But we can't necessarily say what every 802.11 substandard is going to do with channels and spectrum in the future, can we? Making the mapping API flexible is one way to ensure that we don't get stuck a WE-type trap. Dan [1] Obviously we cannot ever anticipate everything, and nobody should try to excessively future-proof d80211, or nothing will get done. We need to balance extendability with over-anticipation. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
