[wireless-regdb] [RFC] wireless: improve dfs-region intersection.

[Luis R. Rodriguez]

On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote:
> Ben Greear <greearb at candelatech.com> writes:
> 
> > As for being confusing, the current code is nasty and it is very hard
> > to have any idea why things do or do not work, especially if you do not
> > have ability to add printk all over the place to figure out what the
> > code is actually doing.
> 
> Heh, this is exatly what I do when I debug regulatory issues :)

CFG80211_REG_DEBUG isn't too chatty already?

> > I think some more effort should go into printing out a lot more
> > information about the regulator domain decisions, through printk
> > or related call if nothing better is found...
> 
> IMHO the regulatory code is the most fragile part of Linux wireless
> stack 

Changing anything on regulatory can have an impact on many things but
lets be clear of the difference on the nature of quality over impact due
to the nature of what the code does and its impact. I invite you to
compare the code quality on the existing regulatory infrastructure from
what was in place on the atheros driver HAL for regulatory control. Now
*that* was incomprensible and somehow we managed to evolve to something
central and shared on Linux.

Code needs to evolve though and I do agree we need to evolve things
to a more mature foundation. More details on that regards below.

> and needs a rewrite. It needs to be simple and easy to understand.

There is actually quite a bit of documentation:

http://wireless.kernel.org/en/developers/Regulatory
http://wireless.kernel.org/en/developers/Regulatory/processing_rules
http://wireless.kernel.org/en/developers/Regulatory/CRDA
http://wireless.kernel.org/en/developers/Regulatory/wireless-regdb

I'm not familiar with smaller pieces of code on the kernel with as much
documentation as this. The code actually also includes quite a bit of
kdoc and comments. Small code changes however can have an impact though
and as technologies advances we have more complex corner cases and
the state machine of regulatory keeps evolving as such a more evolved
infrastructure is indeed needed to help us cope and ensure we don't
have regressions as we evolve the code.

What we need is a full blown regulatory simulator. That would enable
us to stage things in userapce and provide an easy test suite for
changes, and also do easy test automation. I started work on this a
while ago and got somewhat far to at least call it a good start. It
should enable anyone wishing to work on a rewrite to have a good
base template. The last piece I worked on was making a regulatory
library extracted from CRDA and its why CRDA now has reglib. The
next piece would be making usage of reglib on regsim and then a full
effort on the rewrite can undergo.

The regulatory simulator:

https://github.com/mcgrof/regsim

I found at least one fix which I ended up porting upstream (a042994dd377d)
but since "regulatory rewrite" has always been on the lower end of priorities
I never got to finish this work. The basics are there though and having reglib
on CRDA available should also help with a new evolution on regulatory.

Note that the regsim does include the algorithm proposed by Johannes a
while ago as well (check git log), and in fact based on conversations
with Johannes it seems to there was some confusion over the exact
strategy for that, so my recommendation is to verify this with Johannes
(this might be a good candidate technical discussion at the workshop
being discussed elsewhere).

Lastly, we should check with FreeBSD to see if they really care on
sharing, its why we went through the trouble and relicensed all the
regulatory code to ISC. Last I checked with Adrian sharing was a nice
thought but I don't think it was going to happen, if that's the case
the only other reason to use ISC was to help enable regulatory code
to be used on firmware as well. If that's not something really tangible
we should just end the ISC practice on regulatory and embrace GPLv2
as we do with other kernel code.

Happy to help anyone wishing to undertake this :) Any volunteers?

  Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/wireless-regdb/attachments/20140625/21c1caf7/attachment.sig>