Increases mac80211 memory use by about 95K.
At least Ubuntu, Debian, and Arch Linux already enable
this in their default kernels.
Signed-off-by: Thomas Pedersen <[email protected]>
---
net/mac80211/Kconfig | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 0ecf947..4ca2a49 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -80,14 +80,15 @@ comment "Some wireless drivers require a rate control algorithm"
depends on MAC80211 && MAC80211_HAS_RC=n
config MAC80211_MESH
- bool "Enable mac80211 mesh networking (pre-802.11s) support"
- depends on MAC80211 && EXPERIMENTAL
+ bool "Enable mac80211 mesh networking (802.11s) support"
+ depends on MAC80211
+ default y
---help---
- This options enables support of Draft 802.11s mesh networking.
- The implementation is based on Draft 2.08 of the Mesh Networking
- amendment. However, no compliance with that draft is claimed or even
- possible, as drafts leave a number of identifiers to be defined after
- ratification. For more information visit http://o11s.org/.
+ This options enables support for 802.11s mesh networking. The
+ implementation is based on the 11s amendment introduced in IEEE
+ 802.11-2012. An effort has been made to be standard-compliant, so If
+ you notice something amiss, please contact the maintainers. For more
+ information visit http://o11s.org/.
config MAC80211_LEDS
bool "Enable LED triggers"
--
1.7.10.4
On Sun, 2013-02-17 at 21:58 +0800, Yeoh Chun-Yeow wrote:
> http://o11s.org seems not active.
I guess it should be open80211s.org
johannes
http://o11s.org seems not active.
---
Chun-Yeow
On Sun, Feb 17, 2013 at 3:22 AM, Thomas Pedersen <[email protected]> wrote:
> Increases mac80211 memory use by about 95K.
>
> At least Ubuntu, Debian, and Arch Linux already enable
> this in their default kernels.
>
> Signed-off-by: Thomas Pedersen <[email protected]>
> ---
> net/mac80211/Kconfig | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
> index 0ecf947..4ca2a49 100644
> --- a/net/mac80211/Kconfig
> +++ b/net/mac80211/Kconfig
> @@ -80,14 +80,15 @@ comment "Some wireless drivers require a rate control algorithm"
> depends on MAC80211 && MAC80211_HAS_RC=n
>
> config MAC80211_MESH
> - bool "Enable mac80211 mesh networking (pre-802.11s) support"
> - depends on MAC80211 && EXPERIMENTAL
> + bool "Enable mac80211 mesh networking (802.11s) support"
> + depends on MAC80211
> + default y
> ---help---
> - This options enables support of Draft 802.11s mesh networking.
> - The implementation is based on Draft 2.08 of the Mesh Networking
> - amendment. However, no compliance with that draft is claimed or even
> - possible, as drafts leave a number of identifiers to be defined after
> - ratification. For more information visit http://o11s.org/.
> + This options enables support for 802.11s mesh networking. The
> + implementation is based on the 11s amendment introduced in IEEE
> + 802.11-2012. An effort has been made to be standard-compliant, so If
> + you notice something amiss, please contact the maintainers. For more
> + information visit http://o11s.org/.
>
> config MAC80211_LEDS
> bool "Enable LED triggers"
> --
> 1.7.10.4
>
> _______________________________________________
> Devel mailing list
> [email protected]
> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
On Mon, Feb 18, 2013 at 6:19 AM, Johannes Berg
<[email protected]> wrote:
> On Sat, 2013-02-16 at 11:22 -0800, Thomas Pedersen wrote:
>> Increases mac80211 memory use by about 95K.
>>
>> At least Ubuntu, Debian, and Arch Linux already enable
>> this in their default kernels.
>
> *shrug*
>
> I guess I don't really see a problem with this, although only a small
> subset of drivers really supports it. Anyone really wanting to build for
> a small system will probably turn it off anyway.
>
> OTOH, if distros enable it, I also don't see much point in changing
> it ;-)
Heh, good point. I guess this is an attempt to elevate mesh from the
status of "2nd-class citizen" into the realm of "good enough to
default =y" :)
If it's all the same to you I'll go ahead and submit this as a PATCH then.
--
Thomas
Hi Johannes,
On Tue, Feb 19, 2013 at 1:19 AM, Johannes Berg
<[email protected]> wrote:
> On Sat, 2013-02-16 at 11:22 -0800, Thomas Pedersen wrote:
>> Increases mac80211 memory use by about 95K.
>>
>> At least Ubuntu, Debian, and Arch Linux already enable
>> this in their default kernels.
>
> *shrug*
>
> I guess I don't really see a problem with this, although only a small
> subset of drivers really supports it. Anyone really wanting to build for
> a small system will probably turn it off anyway.
>
> OTOH, if distros enable it, I also don't see much point in changing
> it ;-)
>
> What might be interesting is for drivers to somehow indicate they
> support it? But you wouldn't necessarily want drivers to "select MESH",
> so it'd probably have to be something like not allowing mesh to be
> turned on if no driver is turned on that has it? But that makes it
> complicated again, so it's all probably not worth it.
IIRC, the standard way to do things like that is something like:
config HAVE_MESH_DRIVER
default n
config RANDOM_DRIVER
select HAVE_MESH_DRIVER
config MESH
default y if HAVE_MESH_DRIVER
That way it's default on if drivers are selected which have mesh
support but still user selectable (either to disable or if out-of-tree
drivers want it).
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
Hi Julian,
> > What might be interesting is for drivers to somehow indicate they
> > support it? But you wouldn't necessarily want drivers to "select MESH",
> > so it'd probably have to be something like not allowing mesh to be
> > turned on if no driver is turned on that has it? But that makes it
> > complicated again, so it's all probably not worth it.
>
> IIRC, the standard way to do things like that is something like:
>
> config HAVE_MESH_DRIVER
> default n
>
> config RANDOM_DRIVER
> select HAVE_MESH_DRIVER
>
> config MESH
> default y if HAVE_MESH_DRIVER
>
> That way it's default on if drivers are selected which have mesh
> support but still user selectable (either to disable or if out-of-tree
> drivers want it).
Ah, yes, I was thinking something like that but forgot about the
"default ... if" syntax and gave up trying to reproduce it with "select"
and "depends on" :-)
That seems like the best of both worlds? Thomas?
johannes
On Wed, 2013-02-20 at 10:21 -0800, Thomas Pedersen wrote:
> Yes it's nice we can leave out mesh when not useful, will put this in
> the PATCH. Do you think it will be alright if I go ahead and add the
> 'select' to all supported drivers in the same patch?
Fine with me, I doubt you'd have the driver maintainers complain :)
johannes
On Sat, 2013-02-16 at 11:22 -0800, Thomas Pedersen wrote:
> Increases mac80211 memory use by about 95K.
>
> At least Ubuntu, Debian, and Arch Linux already enable
> this in their default kernels.
*shrug*
I guess I don't really see a problem with this, although only a small
subset of drivers really supports it. Anyone really wanting to build for
a small system will probably turn it off anyway.
OTOH, if distros enable it, I also don't see much point in changing
it ;-)
What might be interesting is for drivers to somehow indicate they
support it? But you wouldn't necessarily want drivers to "select MESH",
so it'd probably have to be something like not allowing mesh to be
turned on if no driver is turned on that has it? But that makes it
complicated again, so it's all probably not worth it.
johannes
On Wed, Feb 20, 2013 at 12:25 AM, Johannes Berg
<[email protected]> wrote:
> Hi Julian,
>
>> > What might be interesting is for drivers to somehow indicate they
>> > support it? But you wouldn't necessarily want drivers to "select MESH",
>> > so it'd probably have to be something like not allowing mesh to be
>> > turned on if no driver is turned on that has it? But that makes it
>> > complicated again, so it's all probably not worth it.
>>
>> IIRC, the standard way to do things like that is something like:
>>
>> config HAVE_MESH_DRIVER
>> default n
>>
>> config RANDOM_DRIVER
>> select HAVE_MESH_DRIVER
>>
>> config MESH
>> default y if HAVE_MESH_DRIVER
>>
>> That way it's default on if drivers are selected which have mesh
>> support but still user selectable (either to disable or if out-of-tree
>> drivers want it).
>
> Ah, yes, I was thinking something like that but forgot about the
> "default ... if" syntax and gave up trying to reproduce it with "select"
> and "depends on" :-)
>
> That seems like the best of both worlds? Thomas?
Yes it's nice we can leave out mesh when not useful, will put this in
the PATCH. Do you think it will be alright if I go ahead and add the
'select' to all supported drivers in the same patch?
--
Thomas