Date: Tue, 21 Jul 2020 12:59:09 -0700 From: Chris <bsd-lists@BSDforge.com> To: <freebsd-wireless@freebsd.org>, freebsd-wireless <freebsd-wireless@freebsd.org> Subject: Re: regdomain.xml Message-ID: <f429089c012869afa7c875fa24e941f3@udns.ultimatedns.net> In-Reply-To: <CAJ-VmomofP8%2B5r1kWTvHXvgd-imERKLOMf_BiQaTY8M8bQCeCw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 21 Jul 2020 09:02:07 -0700 Adrian Chadd adrian.chadd@gmail.com said > hi! > > On Tue, 21 Jul 2020 at 02:06, Aaron <notjanedeere@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 --Chrishelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f429089c012869afa7c875fa24e941f3>