On Tue, 2007-10-16 at 16:40 -0400, Michael Wu wrote: > On Friday 12 October 2007 16:48:30 Johannes Berg wrote: > > (a) the driver registers which channel center frequencies it can > > operate with, it could in theory just be a range (e.g. 2400-2500 > > MHz) or more practically be list of center frequencies. > List would be best, but.. > > > Just > > contains frequencies and possibly hardware dependent values for the > > frequency. This is done in "bands", something like > > FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the > > current "modes". > Being able to just register frequency bands would work for many (but not all) > drivers out there and would be more convenient than listing everything. Yeah but it doesn't help when the user wants to enable/disable certain channels or the regulatory code needs to, so it seems we need to go with a list. > > (b) additionally, the driver registers as flags > > - whether it can support G mode short slot operation > > - whether it can receive B mode short barker preambles > > (both of which are only relevant if it supports 2.4 GHz operation) > I haven't seen any softmac 11b hardware that doesn't support receiving short > preamble yet. Ok, I guess we can add that whenever we have a 2.4GHz channel. > > (d) now, selecting a channel by frequency is unique, but we need to > > give new options to select short slot, short preamble and allowed > > bitrates. > Short preamble? What would the hardware do with this bit? Why hardware? For one, we need to advertise whether we support short preamble or not in our association frame. So we need to know whether the hardware supports it or not (which, together with OFDM support, is basically 802.11g iirc). > > Does anyone see problems with this? > More specific examples of the API you have in mind would be helpful. Don't really have any API in mind yet except for what I posted a long time ago in Luis's thread. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
