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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1221070650.13336.20.camel@californication>
Date:	Wed, 10 Sep 2008 20:17:30 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	linville@...driver.com, johannes@...solutions.net,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 v6] 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 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


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ