"Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> writes: > On Tue, Jun 24, 2014 at 08:47:46AM +0300, Kalle Valo wrote: >> Ben Greear <greearb@xxxxxxxxxxxxxxx> 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? Unfortunately it's not enough. Sometimes I need to debug the regulatory code line by line, it's just that difficult to understand. There are all sort of odd checks everywhere in the code which affect behaviour. >> > 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. Sure. I haven't looked at HAL, but I'm sure what we have in cfg80211 is better. But the way I'm seeing is that everyone are just submitting random fixes for their issues and the code is getting more convuluted in every release :/ And I also see that some of the functionality in regulatory code seems to happen by accident, not by design. So I'm getting very worried about this. > 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. I don't think documentation is the solution here. Documentation is always behind the actual implementation and it doesn't really help to fix bugs. The best is if the code is simple enough so that it documents itself. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
