regdomain.xml

[Chris]

On Tue, 21 Jul 2020 09:02:07 -0700 Adrian Chadd adrian.chadd at gmail.com said

> hi!
> 
> On Tue, 21 Jul 2020 at 02:06, Aaron <notjanedeere at gmail.com> wrote:
> 
> > Howdy FreeBSD wireless mailing list,
> >
> > Looking to help, only item on this list
> > (https://wiki.freebsd.org/WiFi/TodoStuff) I'm competent to address is
> > "net80211 regulatory".  I read the "regdomain" manpage ... no help there.
> >
> 
> Yeah, it's ...old. :-0
> 
> 
> >
> > My assumptions:
> >
> >   * the data you're looking to clean up/update/refactor is
> >     "/etc/regdomain.xml".
> >   * you have some idea what you want this file to look like afterwards
> >     (an example would be very helpful)
> >   * the information you want added is available somewhere (FCC site,
> >     IEEE site, ...)
> >
> 
> Luckily we can just use what's in the linux regulatory domain tables
> because they've already done the work of scouring the regulatory sites for
> their information :-)
> 
> 
> >
> > If my assumptions are correct and no-one's already doing it, my
> > questions are:
> >
> >   * the regulatory database is indexed by SKU, rather than by country.
> >     So adding a new _country_ is actually rather annoyingly difficult.
> >       o There's a <country-codes> section that links to <rd>, so either
> >         someone's already done the work here or I need this item explained.
> >
> 
> The file is organised per-SKU; 'rd' is regulatory domain, not country.
> 
>  * Change the regulatory database code to be indexed by something that
> >     isn't hard-coded, and have the "regulatory domain entry index" map
> >     _to_ an SKU where needed.
> >       o "regulatory database code" meaning <rd id="...">?
> >       o Since SKU in this context is not a Stock Keeping Unit ...
> >         definition please?
> >
> 
> it /is/ stock keeping unit. Ok, so!
> 
> This database is an XML representation of the Atheros regulatory database.
> You can find that in sys/dev/ath/ath_hal/ah_regdomain/ or something similar
> under ath_hal.
> It's organised per-SKU because the Atheros parts are kinda organised that
> way. Eg, there are multiple japan codes because the japan rules state that
> older hardware doesn't need to work with newer rules, but newer hardware
> does. So each respin of the japan regdomain rules created a new SKU.
> 
> 
>  * This lets me do useful things like _update the regulatory database_..
> >       o When you refer to the "regulatory database", do you just mean
> >         "/etc/regdomain.xml"?  And what updates are you trying to do
> >         that are currently difficult?
> >
> 
> Well, it's a pain to update things :-) Eg, if I wanted to update the US I'd
> have to go update all the FCC domains that the US can use. FCC is FCC
> without DFS channels; FCC3 is FCC with DFS channels. It's just a lot of
> work.
> 
>  * extend it to support new frequency ranges (60GHZ, VHF white spaces);
> >     in KHz settings rather than MHz increments;
> >       o Current <freqband>s are in MHz, not hard to change them to KHz.
> >         Would obviously impact every program that reads the file ...
> >       o If I understand correctly, adding new freq ranges is just data
> >         entry.  If so, is there a link to the new frequency ranges you
> >         want added?
> >
> 
> Whatever's in the linux regdomain database would be a good start.
> 
> 
> >   * add VHT flags and 80/80+80/160MHz wide channel widths.
> >       o More data entry.  Link to the data you want added?
> >
> 
> I've added it for FCC. You can see what work it was just to add them there.
> :-)
> 
> 
> > If having me add data, refactor, change hierarchy, etc. is helpful let
> > me know.  If it sounds like there'll be too much handholding, no hard
> > feelings.
> 
> 
> I'm sure we can help out :-)
> 
> So, I'd really like to figure out how to simplify the regdomain.xml file.
> But - we should come up with a firm plan first. Luckily this IS basically
> all userland work. :-)
> 
+1 for the offer to dig in, Aaron!

> What do others think? What should we do?
I vote for recreating it as a CSV file. Would then be easier to work with
and easy to convert to other formats -- json/xml/...

You asked. ;-)
> 
> 
> 
> -adrian

--Chris