Linux CRDA(Central Regulatory Domain Agent)简介

这是一篇介绍CRDA的原文，来自于http://lwn.net/Articles/271037/，这里简单介绍一下。

     通过下面的文章，我们可以获知如下信息：

     1、CRDA作用：

          消除host driver中的冗余regulatory domain code；

          提供更新“regulatory rules”的方法或途径；

          加强不同无线设备的互操作性；

          实现无线软件对于不同地理位置（国家）不同规则的无线设备的兼容性。

    2、无线网络软件实现

          用户空间通过nl80211与内核空间regulatory domain交互；

          80211设备可以通过cfg80211向内核注册自己的硬件设备（性能）。

    更具体的信息请参考下面文章：

     I'd like to request for review and advice for the central regulatory
domain agent (CRDA) we have been working towards in the Linux 802.11
subsystem. I'm including linux-kernel in hopes of a wider review.
Particularly I'd like advice on the best path we can take for the
userspace agent which *could* eventually be required upon userspace,
meaning *most* distributions will package it if they want decent
regulatory 802.11 support. But first let me begin with a brief
overview of the concept of a CRDA, the case for it, and patches
submitted and reviewed so far.* Central regulatory domain agents - a case for itContrary to all other drivers in the different subsystems in the
kernel, 802.11 drivers have local regulatory laws to take into
consideration for operation. To this day, due mainly to certification
requirements, vendors have taken it upon themselves to make their
hardware adhere to all regulatory regions their devices will be sold
in. These requirements are now implemented in software on the host
driver or firmware of the device. The reason for this is to enable the
design of one 802.11 chipset with capabilities to operate in different
geographical regions to reduce the cost of manufacturing, bring down
the price of the products sold, and allow users to make use of their
802.11 devices in different countries they may go to. Another shift in
market trends we are seeing is that of vendors moving away from a
FullMAC [1] design model to a SoftMAC [2] design model for most their
802.11 chipsets; development-wise this means the drivers receive raw
802.11 frames instead of Ethernet frames and hence the need for
mac80211, which provides a driver API to such type of devices and
implements a basic STA MLME [3] in-kernel. Some SoftMAC devices also
require complete regulatory control within the host driver. Some of
these drivers end up implementing their own regulatory domain control
and data structures. Except for the vendor-specific components of the
code, usually frequency, power values and sometimes regulatory domain
values, all of this code can instead be centralized as part of he
802.11 subsystem and shared amongst all the 802.11 drivers. This code
sharing would provide a centralized regulatory domain control for
devices which require regulatory domain control on the host, and
additionally provide *enhanced effort* on our part in the operating
system for compliance to local regulatory laws for devices which may
have *out-of-date rules* or *buggy* regulatory domain control code.The above just addresses the present. What lies ahead for wireless
seems to be making wireless devices smarter, more interoperable, but
always compliant to local regulatory laws. Software Defined Radios
(SDRs) [4] are a breed of wireless devices which are under the horizon
and depending on the definition of an SDR used, can be considered to
already be used and sold in the 802.11 market. Regulatory laws on SDR
are relatively new and are still under review and vary depending upon
geographical region. For example, the "The Software Freedom Law Center
(SFLC) has examined the Federal Communication Commission's (FCC)
rules", which when into into effect on July 6, 2007, "governing
Software Defined Radio (SDR) devices and concluded that the rules do
not restrict the activities of independent developers and distributors
of Free and Open Source Software (FOSS) designed for use with SDR
devices." [5] It also found that the "FCC's SDR rules create an
opportunity for wireless hardware manufacturers, the FOSS community,
and the FCC to communicate openly and productively about the ability
of public disclosure and open standards to strengthen the security and
robustness of wireless devices." With this in mind I think it is
important to try to help the vendors achieve compliance with local
regulatory laws and still remain compliant by supporting FOSS. Its
arguable if this is possible or not, but let us please not get into
this now; what I believe is more important is that we pave the way for
the best technology possible for regulatory rules for 802.11 and also
SDRs. A strong CRDA goes hand-in-hand with advancing SDRs as the
attributes can be expanded as the technology does -- more modulations
supported, different bands added, and so forth. Additionally a
Frequency Broker [6] (note: this link is old and needs some updating
but has the general idea) can later be added to register frequencies,
power level, modulations which each wireless device present on a host
is using to help with interoperability.A CRDA together with a Frequency Broker can therefore eliminate
redundant regulatory domain code on host drivers, provide a convenient
mechanism to update regulatory rules, and enhance interoperability
between different type of wireless devices.* Implementation of the CRDAI posted my first series on October of 2006 [7] however the first
series stuffed everything into the kernel, the data structures were
overly complex, and no solid integration with mac80211 (d80211 then)
was provided [8]. The second series, posted on September of 2007 [9],
still left everything in the kernel, was more simplified and had
integration with mac80211 and cfg80211, additionally zd1211rw was
ported to the new framework and tested. After some discussion one the
lists and IRC it was determined we should just move the database of
regulatory domains into userspace and have just one regulatory domain
defined in kernel space at a time. Userspace can then pass to kernel
space a regulatory domain via the new nl80211. 802.11 devices can then
register with cfg80211 its hardware capabilities and only allowed
"channels" will be enabled, all others will be disabled. We can keep
two standard regulatory domains in kernel space, however: a world
regulatory domain which is a common denominator of all regulatory law
-- its basically FCC with relaxed power requirements and no 5 GHz
communication -- and a debug regulatory domain which enables
everything.The regulatory domain used on the 802.11 subsystem will reflect the
user's latest selected preference if one is set (this will override
all settings), an 802.11 card's EEPROM reading, or country defined by
an 802.11d country information element broadcast by a local access
point (depending upon configuration and preferences).* Request for advice:cfg80211 can take the "installed" regulatory domain and only enable
power settings / frequency settings dependent upon current defined
regulatory rules. But in order to install a regulatory domain into the
kernel we need userspace to upload it via nl80211. This is easily
accomplished once userspace has one defined via structures defined in
nl80211 for a regulatory domain. Regulatory domain rules vary,
however, and I expect users to contribute on expanding the rules to be
as accurate as possible. As such it *is* expected that as time goes by
userspace will have rules updated, attributes added (will go
hand-in-hand with nl80211 updates), or completely new regulatory
domains defined. We therefore need a way to keep a database of
regulatory domains, and a way to parse this database to finally hand
to the kernel the desired regulatory domain.My initial take on this was to use a berkely db or sqlite db for the
database and keep this local on hosts, however this would enforce
certain package requirements upon most installations and do not think
that's the best approach. Another approach is to keep the real
database only on some development machines and let people send updates
to it as well as view the database online. An output of the database
can then be dumped as a flat file to a host in some format. The
regulatory daemon would then parse this flat file and upon changes to
the file update its local database of regulatory domains. I'd like
feedback on suggestions for the file format used which would keep
distributions requirements at a minimal. If there is some extremely
light weight and acceptable database and database API most of us
wouldn't mind seeing on most installs please name them too (although I
don't think this is really a good idea).My preference is to keep the real database on a development box which
has some web interface which people can use to view. Ideally users can
then send updates to the database to provide updates to rules. The
database can then be dumped and an application used to generate some
flat file. Distributions can then pick this flat file up and propagate
it to users. A user's host would have the CRDA userspace daemon
running, and once a new file is downloaded the regulatory daemon is
informed about it. The reg daemon would then parse the flat file and
update its internal database and new regulatory rules would become
available to the kernel. What I am not sure on is the best format to
use for the flat file.

http://blog.csdn.net/hengkong_horse/article/details/8936566

Linux CRDA(Central Regulatory Domain Agent)简介相关推荐

Linux CRDA(Central Regulatory Domain Agent)
这是一篇介绍CRDA的原文,来自于http://lwn.net/Articles/271037/,这里简单介绍一下. 通过下面的文章,我们可以获知如下信息: 1.CRDA作用: 消除host driv ...
Calling CRDA to update world regulatory domain
最近在移植无线网卡驱动AR9271,在使用网卡遇到了一个问题,请教下各位大侠? 移植环境为: 主机操作系统: Linux ubuntu 3.5.0-34-generic 目标系统: ...
linux设备驱动程序架构的研究,Linux设备驱动程序学习（12）-Linux设备模型（底层原理简介）...
Linux设备驱动程序学习(12) -Linux设备模型(底层原理简介) 以<LDD3>的说法:Linux设备模型这部分内容可以认为是高级教材,对于多数程序作者来说是不必要的.但是我个人认 ...
Linux之apt-get：apt-get的简介、安装、使用方法之详细攻略
Linux之apt-get:apt-get的简介.安装.使用方法之详细攻略目录 apt-get的简介 apt-get的安装 apt-get的使用方法 apt-get的简介 apt-get,是一条li ...
永久把linux系统chrome的user agent 改成win10系统的
永久把linux系统chrome的user agent 改成win10系统的请谨慎修改:此方法会导致播放不了flash视频 1.找到google-chrome.desktop,先做一个备份.一般路径 ...
regulatory domain
这是个好像很专业的词汇,在Porting Android Wifi的过程中看到这个设置,里面有 11 channels, 13 channels, 14 channels, 看起来很不理解,googl ...
Android Wi-Fi Regulatory domain controlle the channel(以QCOM平台为例)
How channel is controlled for a regulatory domain? For example, whether ch14 is available for JP reg ...
Linux 中的 netcat 网络工具简介
Linux 中的 netcat 网络工具简介 Apr 3, 2020 | Linux | linux netcat netcat 是 Linux 系统中的网络工具,其通过 TCP 和 UDP 协议 ...
java agent简介
java agent简介主要就是两种,一种的方法是premain,一种是agentmain.这两种的区别是: premain是在jvm启动的时候类加载到虚拟机之前执行的 agentmain是可以在j ...

Linux CRDA(Central Regulatory Domain Agent)简介

Linux CRDA(Central Regulatory Domain Agent)简介相关推荐

最新文章

热门文章