new regdb file format

new regdb file format

[Johannes Berg]

Hi,

I spent a bit of time thinking about a file format that would be more
extensible, yet still be loadable into the kernel without having to
parse it into new data structures in the kernel, i.e. be easy enough to
read when needed.

My considerations
 * must be extensible in some way
 * should be relatively dense
 * 

johannes

Re: new regdb file format

[Johannes Berg]

Err. Let's try that again.

I spent a bit of time thinking about a file format that would be more
extensible, yet still be loadable into the kernel without having to
parse it into new data structures in the kernel, i.e. be easy enough to
read when needed.

My considerations
 * must be extensible in some way
 * should be relatively dense/small to not use too much kernel memory
 * should still be reasonably easy to parse/read

I came up with a file format that's similar to the existing
regulatory.bin format, but with the following changes:
 * put the DFS region into a reg rule collection
 * put the frequency range and power rules directly into each reg rule
   (i.e. don't try to normalize them)
 * have a length field in the collection and rule structures so that we
   can extend them with new fields
 * use more compact pointers, i.e. u16 offsets, by aligning everything
   to 4 bytes and shifting the offsets by 2 bits, this allows for
   256KiB database files which seems large enough

More documentation is here:
https://wireless.wiki.kernel.org/en/developers/todo-list/regdb-file
-format

I put together a small sample program to create such a file from db.txt
(https://p.sipsolutions.net/1c42079f2e658a82.txt) and one to print such
a file (https://p.sipsolutions.net/8c180172adbe0ad3.txt)

Thoughts?

johannes

Re: new regdb file format

[Johannes Berg]

On Wed, 2015-10-14 at 23:01 +0200, Johannes Berg wrote:
> 
> More documentation is here:
> https://wireless.wiki.kernel.org/en/developers/todo-list/regdb-file
> -format
> 

FWIW, the file currently ends up being 3676 bytes with a new field for
the CAC timeout already added (though without signature, of course,
since I'm assuming that to be external with firmware load signing or
whatever)

regulatory.bin is currently 4592 bytes.

johannes

Re: new regdb file format

[Eliad Peller]

On Thu, Oct 15, 2015 at 12:01 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Err. Let's try that again.
>
> I spent a bit of time thinking about a file format that would be more
> extensible, yet still be loadable into the kernel without having to
> parse it into new data structures in the kernel, i.e. be easy enough to
> read when needed.
>
> My considerations
>  * must be extensible in some way
>  * should be relatively dense/small to not use too much kernel memory
>  * should still be reasonably easy to parse/read
>
> I came up with a file format that's similar to the existing
> regulatory.bin format, but with the following changes:
>  * put the DFS region into a reg rule collection
>  * put the frequency range and power rules directly into each reg rule
>    (i.e. don't try to normalize them)
>  * have a length field in the collection and rule structures so that we
>    can extend them with new fields
>  * use more compact pointers, i.e. u16 offsets, by aligning everything
>    to 4 bytes and shifting the offsets by 2 bits, this allows for
>    256KiB database files which seems large enough
>
> More documentation is here:
> https://wireless.wiki.kernel.org/en/developers/todo-list/regdb-file
> -format
>
while at it - is there any way to indicate exclusion of some channels?
e.g. channels 38/42 in US (the current rule is "(5170 - 5250 @ 40)",
which doesn't seem to forbid them)

Eliad.

Re: new regdb file format

[Johannes Berg]

On Mon, 2015-10-19 at 14:28 +0300, Eliad Peller wrote:

> while at it - is there any way to indicate exclusion of some 
> channels?
> e.g. channels 38/42 in US (the current rule is "(5170 - 5250 @ 40)",
> which doesn't seem to forbid them)
> 

Hm? Why would you want to do that, if you are allowed to use that band?

johannes

Re: new regdb file format

[Eliad Peller]

On Mon, Oct 19, 2015 at 2:31 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2015-10-19 at 14:28 +0300, Eliad Peller wrote:
>
>> while at it - is there any way to indicate exclusion of some
>> channels?
>> e.g. channels 38/42 in US (the current rule is "(5170 - 5250 @ 40)",
>> which doesn't seem to forbid them)
>>
>
> Hm? Why would you want to do that, if you are allowed to use that band?
>
The spec seems to indicate the allowed channel set for each operating
class, and some channels are allowed only in some countries (tables
E-1 vs. E-2 in 802.11-2012 Annex E).

Eliad.

Re: new regdb file format

[Johannes Berg]

On Mon, 2015-10-19 at 14:52 +0300, Eliad Peller wrote:
> 
> > Hm? Why would you want to do that, if you are allowed to use that 
> > band?
> > 
> The spec seems to indicate the allowed channel set for each operating
> class, and some channels are allowed only in some countries (tables
> E-1 vs. E-2 in 802.11-2012 Annex E).
> 

But that's a different problem in a way - the regulatory database only
tries to encode the legal restrictions, not the spec restrictions.

johannes

Re: new regdb file format

[Eliad Peller]

On Mon, Oct 19, 2015 at 2:53 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2015-10-19 at 14:52 +0300, Eliad Peller wrote:
>>
>> > Hm? Why would you want to do that, if you are allowed to use that
>> > band?
>> >
>> The spec seems to indicate the allowed channel set for each operating
>> class, and some channels are allowed only in some countries (tables
>> E-1 vs. E-2 in 802.11-2012 Annex E).
>>
>
> But that's a different problem in a way - the regulatory database only
> tries to encode the legal restrictions, not the spec restrictions.
>
that's a good point :)

thanks,
Eliad.