RFC: more finegrained configuration of 11b/11g rates and modulations

[Denis Vlasenko]

> > I am going to do some unification work on rate support for
> > 11b/11g, immediately targeting acx111, prism54 and possibly
> > hostap.
> >
> > The proposal is to use ASCII formatted private ioctl:
> >
> > iwpriv <iface> set_rate "1,2,5,11 11p,24d"
[snip]
>
> 	Wow !
>
> 	My first comment is that I would prefer to protect the dumb
> users to have to mess up with all this complex stuff. Of course, it's
> desirable to have that in an Access Point, but I believe a client card
> should be smart enough to figure out what to use.
> 	My personal goal is to keep the main API simple. Of course,
> you are free to do whatever you want in iwpriv.

I don't think it is possible to have 11g rate/modulation config
simple and complete at the same time.

While in simple cases iwconfig's rate command is sufficient,
sooner or later you will want total control over what rates
to use and what to avoid.

Today, it is plain impossible to instruct my acx111 to _not_
use 22 pbcc modulation with prism54 AP, short of code
modifications.

hostap, as usual, is ahead of others and already have
iwpriv basic_rates and oper_rates, but it uses
a bitmap, which was logical in the days of 11b.

> 	Second comment is that not all hardware will allow this much
> flexibility and won't support all rate. I don't know how you will deal
> with that. You may need a command to export "capabilities" so that the
> user/app know how to create a string that can work.

Simple. If hardware can't satisfy a particular request, it fails ioctl.

> 	Third comment is that I believe it's better to keep text
> parsers out of the kernel for various reasons, especially that this
> one is not totaly trivial. If you want, we could include the text
> parser in iwpriv.c (similar to roam/port).

Linus would disagree with you. Both proc and sysfs are mostly ASCII.
Also, binary interfaces tend to suffer from "oh, we've overflowed that
32 bit entity, need new syscall" syndrome. I don't want to tie myself
to current 11b/g/a idiosyncrasies. ASCII is more flexible.

Parser is not trivial, but is already done. :)

> 	But, don't let my comment influence too much your work ;-)
> 	Have fun...

Yeah
--
vda