I would not mix rates with modulation and other channel parameters.
It looks better to bind frequency with parameters like modulation, channel
width (10Mzh narrow channels in japan) etc. , into 'channel' number or
(channel,band) tuple.
For supported and optional rate, IE (info element) format may be the best
choice.
On Sunday 15 August 2004 19:10, Denis Vlasenko wrote:
DV> On Sunday 15 August 2004 16:21, Margit Schubert-While wrote:
DV> > I disagree with this.
DV> > We don't need parameter parsing either in the driver or in
DV> > wireless.c.
DV> > There is a perfectly good infrastructure in wireless tools iwpriv.c
DV> > Take a look at around line 375 in iwpriv.c for the
DV> > existing example of IW_PRIV_TYPE_FLOAT.
DV> > This could be adapted for this purpose (IW_PRIV_TYPE_BITRATE ?)
DV> > and (mis)use the iw_freq structure to pass the values and extra info.
DV>
DV> Ok. And then we will need to parse that data into format suitable for
DV> prism54 in prism54 driver, and into format suitable for acx100/acx111
DV> in acx100 driver, etc... Most probably this code will be ugly, because
DV> different hardware have completely different way of setting tx rate.
DV> Even acx100 and acx111 are different, not to say acx100 and prism54.
pgpSo3ibRYdtk.pgp
Description: PGP signature
|