linux-kernel - Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1220668394.6714.109.camel@californication>
Date:	Sat, 06 Sep 2008 04:33:14 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	johannes@...solutions.net, linville@...driver.com,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 v5] cfg80211: Add new wireless regulatory
	infrastructure

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 a module parameter
> * all rules are 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
> (CRDA) through udev allowing distributions to update regulatory rules
> without updating the kernel. Updates on regulatory rules can
> now be left as an independent effort.

can we get a small document in Documentation/ that describes what has to
be done for CRDA. That would help to ease the adaption and would allow
us to point people to it. Nothing fancy, but some quick notes where to
find it and what to put where.

> 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.

Do we have an example for all the possible ways? I think about something
to help driver maintainers to move over and use the infrastructure the
right way.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/