Date: Sun, 9 Aug 2020 12:47:35 -0400 From: Aaron <notjanedeere@gmail.com> To: freebsd-wireless@freebsd.org Subject: Re: regdomain.xml [was also: - Linux wireless-regdb] Message-ID: <fa85f19f-485d-ae2c-cc7c-798dd9c59182@gmail.com> In-Reply-To: <083B7D36-2175-46DC-9C9A-FEA8673482E8@lists.zabbadoz.net> References: <b1404b90-87a5-8f78-aeb4-cf31bc1a704b@gmail.com> <adef735d-c3a1-1723-936d-1cf3e4b819c9@gmail.com> <CAJ-VmokM4Kxi%2BDKOGVJp6B4y7dOm8=Rm81eZQYYSHUcmNY2bDA@mail.gmail.com> <c49d1f38-2fe3-46f0-8330-c472de16a9da@gmail.com> <083B7D36-2175-46DC-9C9A-FEA8673482E8@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
The documentation portion seems like the first step, is there a wiki for proposed changes where we could start? To get started, is there any existing documentation we can refer to? I think the answer is no, and it's down to someone who understand it going through the code to find answers ... On 8/9/2020 11:37 AM, Bjoern A. Zeeb wrote: > Hi, > > I’ll just join in on the last email in the thread not replying to > anything specific. > > Having gone through some of the stuff lately myself in order to put > [1] out (which is also includes a few things to discuss) I’ll try to > summarise a few things I’ve learnt and thought of, which confused me > over the time: > > - SKU - what does it actually stand for? Does it really belong into > our regdomain? > > - why are the freqbands prefixes with “H”, “F”, .. and what do these > magic letters stand for? > > - We have netbands, freqbands, and bands. None of these are actually > describing the actual frequency ranges (as the linux-db does). > > - The freqbands seems to start and end on the center frequency of the > first/last chansep spaced channel. In the old days that was less > confusing I guess as to now with 4x20 for VHT80. > > - I am still unclear as to where we should map channels to frequency > because we are half-hearted doing that partially for upper and lower > bounds of freqbands currently. As such I have different freqbands for > VHT20 vs. VHT40/80/160 as there are cases where there is an extra 20 > channel not part of 80s. > > - I’d love to have the freqbands actually describe the frequency > limits and have the mappings of channels within them elsewhere; I > have no idea how/where Linux is doing that. > > - I’d love to have general freqbands and groups of them independent of > the netbands. > > - I do not actually understand what netbands are for given we have the > IEEE80211_CHAN_ set appropriately. It’s for simplicity later but > there is a lot of duplication. That said, some of these > IEEE80211_CHAN_* flags do not actually belong to the regulatory limits > either but are an 802.11 channel description. > > - This all leads to confusion currently as to how we setup > bands/channels/.. I made a mistake by accident and the list of > combinations we checked in ifconfig exploded to 350.000 for whether a > channel was valid. Clearly told me that the organisation does not > seem to be right. > > - I was wondering if for clarity we can break up regdomain.xml into > multiple files? > > - One thing I don’t like on the Linux version is that for, say ETSI, > the information is basically copied per EU member state. I love our > reference model there. I don’t mind having etsi, etsi1, etsi2 if I > can then say 20 countries it’s etsi2 and be done. I think that is > something essential and good we have. > > > - I do like our more structured format a lot more than the Linux one. > > - We are lacking a few things, DFS and INDOORS and maxpower are not > the only things which matter these days. You may notice > “wmmrule=ETSI” in the Linux reg-db, for example. > > - I wonder if what we actually want is a multi-layer thingy inheriting > one from another or if we want a pure-regdomain (not knowing about > channels) and more logic elsewhere which deals with putting WiFi > things into that)? > > > - I think it’ll need a bit more than simply restructuring > regdomain.xml; I think doing it will probably also need a bit more > (a) documentation on what each bit means and tries to accomplish) and > (b) a more clear separation between frequencies and restrictions and > 802.11 channels and with that a bit more downward code changes. > > - I would really love to see some of these things sorted and I’d love > if the thread would stay alive. > > Just my 5cts, > Bjoern > > > [1] https://reviews.freebsd.org/D25999 > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to > "freebsd-wireless-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fa85f19f-485d-ae2c-cc7c-798dd9c59182>