netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Rick Jones <rick.jones2@hp.com>,
	Christoph Hellwig <hch@infradead.org>,
	netdev@vger.kernel.org
Subject: Re: [RFC] Geographical/regulatory information for ieee80211
Date: Wed, 26 Apr 2006 19:54:31 -0500	[thread overview]
Message-ID: <44501647.8070308@lwfinger.net> (raw)
In-Reply-To: <4443D694.8090809@hp.com>

Rick Jones wrote:
> Christoph Hellwig wrote:
>> On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
>>
>>> I am planning on writing a new routine to be added to 
>>> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo 
>>> object given a country code. The new routine will eliminate the need 
>>> for each driver to do their own.
>>
>>
>> This sounds like a generally good idea, but the question is:  do we want
>> this inside a kernel module or in userspace, either like the regulartory
>> daemon intel has (unfortunately in binary only form) or as a simple init
>> script.  I really don't want to recompile my kernel just because 
>> regulations
>> changed, and they seems to do that quite often.
> 
> Yet I would expect the regulatory bodies to look less favorably on 
> something more easily maleable by the end-user.

I don't think it would make that much difference as the user could easily lie about their locality 
and get any set of parameters that they wanted. Intel avoids this problem by hiding the locality in 
an EEPROM (ipw2200) or by combining the EEPROM information with the binary-only daemon (3945).

I am leaning toward putting the geographical information into a userland daemon. That way we won't 
have to patch the kernel every time a country modifies its regulations. In addition, the kernel will 
be smaller. The downside is that the daemon will have to be updated and supplied in some convenient 
form, perhaps as part of a wireless tools package.

Larry

  reply	other threads:[~2006-04-27  0:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-14  0:59 [RFC] Geographical/regulatory information for ieee80211 Larry Finger
2006-04-14 11:41 ` Ulrich Kunitz
2006-04-14 11:58   ` Faidon Liambotis
2006-04-14 15:27 ` Jouni Malinen
2006-04-14 20:01   ` Larry Finger
2006-04-15 17:07   ` Faidon Liambotis
2006-04-15 17:47 ` Christoph Hellwig
2006-04-17 17:55   ` Rick Jones
2006-04-27  0:54     ` Larry Finger [this message]
2006-04-28 11:17       ` Harald Welte
2006-04-29  0:31       ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44501647.8070308@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=hch@infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).