Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Marcel Holtmann]

Hi Luis,

> This adds the new wireless regulatory infrastructure. The
> main motiviation behind this was to centralize regulatory
> code as each driver was implementing their own regulatory solution,
> and to replace the initial centralized code we have where:
> 
> * only 3 regulatory domains are supported: US, JP and EU
> * regulatory domains can only be changed through module parameter
> * all rules were built statically in the kernel
> 
> We now have support for regulatory domains for many countries
> and regulatory domains are now queried through a userspace agent
> through udev allowing distributions to update regulatory rules
> without updating the kernel.
> 
> Each driver can regulatory_hint() a regulatory domain
> based on either their EEPROM mapped regulatory domain value to a
> respective ISO/IEC 3166-1 country code or pass an internally built
> regulatory domain. We also add support to let the user set the
> regulatory domain through userspace in case of faulty EEPROMs to
> further help compliance.

thanks for the write-up and examples. I like it a lot and gives driver
maintainers a nice understanding what to do.

While reading through it, I came to think about regulatory_hint(). So is
there a use case where would give it the alpha2 code and the domain
itself at the same time? If not, then it would make more sense to split
this into two functions. Maybe something regulatory_alpha2_hint() and
regulatory_domain_hint(). Just a thought.

Regards

Marcel

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Luis R. Rodriguez]

On Wed, Sep 10, 2008 at 11:17 AM, Marcel Holtmann
<holtmann@linux.intel.com> wrote:
> Hi Luis,
>
>> This adds the new wireless regulatory infrastructure. The
>> main motiviation behind this was to centralize regulatory
>> code as each driver was implementing their own regulatory solution,
>> and to replace the initial centralized code we have where:
>>
>> * only 3 regulatory domains are supported: US, JP and EU
>> * regulatory domains can only be changed through module parameter
>> * all rules were built statically in the kernel
>>
>> We now have support for regulatory domains for many countries
>> and regulatory domains are now queried through a userspace agent
>> through udev allowing distributions to update regulatory rules
>> without updating the kernel.
>>
>> Each driver can regulatory_hint() a regulatory domain
>> based on either their EEPROM mapped regulatory domain value to a
>> respective ISO/IEC 3166-1 country code or pass an internally built
>> regulatory domain. We also add support to let the user set the
>> regulatory domain through userspace in case of faulty EEPROMs to
>> further help compliance.
>
> thanks for the write-up and examples. I like it a lot and gives driver
> maintainers a nice understanding what to do.

Thanks :)

> While reading through it, I came to think about regulatory_hint(). So is
> there a use case where would give it the alpha2 code and the domain
> itself at the same time? If not, then it would make more sense to split
> this into two functions.

Nope, you either pass an alpha2 or an rd domain which is built by you
(and in that rd structure you can set the alpha2 to your iso3166
alpha2 or "99" if unknown).

> Maybe something regulatory_alpha2_hint() and
> regulatory_domain_hint(). Just a thought.

That's how I had it originally but decided to condense it to one
routine since as you could see they pretty much do the same thing
except the case where the rd is provided it calls set_regdom().
Setting it back to use two routines if fine by me too. What is better?
Can we just get this merged and then we can flip it around if
necessary? :) I'm tired of carrying this around.

  Luis

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Marcel Holtmann]

Hi Luis,

> > While reading through it, I came to think about regulatory_hint(). So is
> > there a use case where would give it the alpha2 code and the domain
> > itself at the same time? If not, then it would make more sense to split
> > this into two functions.
> 
> Nope, you either pass an alpha2 or an rd domain which is built by you
> (and in that rd structure you can set the alpha2 to your iso3166
> alpha2 or "99" if unknown).
> 
> > Maybe something regulatory_alpha2_hint() and
> > regulatory_domain_hint(). Just a thought.
> 
> That's how I had it originally but decided to condense it to one
> routine since as you could see they pretty much do the same thing
> except the case where the rd is provided it calls set_regdom().
> Setting it back to use two routines if fine by me too. What is better?
> Can we just get this merged and then we can flip it around if
> necessary? :) I'm tired of carrying this around.

my take on this is that if from an API perspective you can only use one
parameter or the other, then it should be two functions.

Regards

Marcel

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Luis R. Rodriguez]

On Wed, Sep 10, 2008 at 3:07 PM, Marcel Holtmann
<holtmann@linux.intel.com> wrote:
> Hi Luis,
>
>> > While reading through it, I came to think about regulatory_hint(). So is
>> > there a use case where would give it the alpha2 code and the domain
>> > itself at the same time? If not, then it would make more sense to split
>> > this into two functions.
>>
>> Nope, you either pass an alpha2 or an rd domain which is built by you
>> (and in that rd structure you can set the alpha2 to your iso3166
>> alpha2 or "99" if unknown).
>>
>> > Maybe something regulatory_alpha2_hint() and
>> > regulatory_domain_hint(). Just a thought.
>>
>> That's how I had it originally but decided to condense it to one
>> routine since as you could see they pretty much do the same thing
>> except the case where the rd is provided it calls set_regdom().
>> Setting it back to use two routines if fine by me too. What is better?
>> Can we just get this merged and then we can flip it around if
>> necessary? :) I'm tired of carrying this around.
>
> my take on this is that if from an API perspective you can only use one
> parameter or the other, then it should be two functions.

This is reasonable, I'll respin, yet once again...

  Luis

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Marcel Holtmann]

Hi Luis,

> >> > While reading through it, I came to think about regulatory_hint(). So is
> >> > there a use case where would give it the alpha2 code and the domain
> >> > itself at the same time? If not, then it would make more sense to split
> >> > this into two functions.
> >>
> >> Nope, you either pass an alpha2 or an rd domain which is built by you
> >> (and in that rd structure you can set the alpha2 to your iso3166
> >> alpha2 or "99" if unknown).
> >>
> >> > Maybe something regulatory_alpha2_hint() and
> >> > regulatory_domain_hint(). Just a thought.
> >>
> >> That's how I had it originally but decided to condense it to one
> >> routine since as you could see they pretty much do the same thing
> >> except the case where the rd is provided it calls set_regdom().
> >> Setting it back to use two routines if fine by me too. What is better?
> >> Can we just get this merged and then we can flip it around if
> >> necessary? :) I'm tired of carrying this around.
> >
> > my take on this is that if from an API perspective you can only use one
> > parameter or the other, then it should be two functions.
> 
> This is reasonable, I'll respin, yet once again...

get an agreement with Johannes on the naming. Either _alpha2_hint() or
_hint_alpha2(). Not sure what the others are preferring.

Regards

Marcel

Re: [PATCH 1/2 v6] cfg80211: Add new wireless regulatory infrastructure

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Thu, 2008-09-11 at 00:25 +0200, Marcel Holtmann wrote:

> get an agreement with Johannes on the naming. Either _alpha2_hint() or
> _hint_alpha2(). Not sure what the others are preferring.

I very very very slightly prefer the latter, but really, what gives? :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]