LinuxLists.cc - iwlwifi-driver card doesn't work with 3.19-rc2+

[permalink] [raw]

Subject: RE: iwlwifi-driver card doesn't work with 3.19-rc2+

>
> On 12/30/2014 09:23 AM, Emmanuel Grumbach wrote:
> > On Tue, Dec 30, 2014 at 3:33 PM, Jiri Kosina <[email protected]> wrote:
> >>
> >> Hi,
> >>
> >> I just booted current Linus' tree (5faa0154fe33) on my x200s
> >> thinkpad, and wifi doesn't work. iwconfig is telling me that wlan0
> >> interface has no wireless extensions.
> >>
> >
> > So why do you used them?
> > They have been deprecated for a couple of years now. You should be
> > using nl80211 based tools such as iw.
>
> A couple of years is not very long where userspace is concerned.
>
Well - the decently new wireless tools do talk nl80211.
You can still enable it (CFG80211_WEXT).
It has been disabled by:

commit 24a0aa212ee2dbe44360288684478d76a8e20a0a
Author: Johannes Berg <[email protected]>
Date: Fri Nov 28 12:14:06 2014 +0100

cfg80211: make WEXT compatibility unselectable
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?

2014-12-30 15:03:51

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 30 Dec 2014, Emmanuel Grumbach wrote:

> > I just booted current Linus' tree (5faa0154fe33) on my x200s thinkpad, and
> > wifi doesn't work. iwconfig is telling me that wlan0 interface has no
> > wireless extensions.
>
> So why do you used them?
> They have been deprecated for a couple of years now. You should be
> using nl80211 based tools such as iw.

My userspace wireless setup tool (wicd) is using wireless extensions, and
even the most recent version uses solely that.

I am pretty sure that's not the only tool in the world.

> > Previous kernel that is known to work on this machine is 3.18-rc5. I
> > can do a bisect if needed, but wanted to ask in case this is a known
> > problem.
>
> 3.19 is the first kernel that actually removed the wireless extensions.

That's userspace breakage I am pretty sure a LOT of people will be
hitting. I don't think this fits into the way we are maintaining userspace
compatibility at all.

--
Jiri Kosina
SUSE Labs

2014-12-30 15:21:23

[permalink] [raw]

Subject: RE: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote:

> > > So why do you used them?
> > > They have been deprecated for a couple of years now. You should be
> > > using nl80211 based tools such as iw.
> >
> > A couple of years is not very long where userspace is concerned.
> >
> Well - the decently new wireless tools do talk nl80211.

With 3.18-rc5, I get this:

# iwconfig --version
iwconfig Wireless-Tools version 30
Compatible with Wireless Extension v11 to v22.

Kernel Currently compiled with Wireless Extension v22.

wlan0 Recommend Wireless Extension v21 or later,
Currently compiled with Wireless Extension v22.

With 3.19-rc, I get (with the same userspace) this:

# iwconfig --version
iwconfig Wireless-Tools version 30
Compatible with Wireless Extension v11 to v22.

Cannot read /proc/net/wireless

And nothing else (iwlist, etc) works either. This is with

# rpm -qi wireless-tools | grep Ver
Version : 30.pre9

from openSUSE 13.2. That's not decently new enough?

> You can still enable it (CFG80211_WEXT).
> It has been disabled by:
>
> commit 24a0aa212ee2dbe44360288684478d76a8e20a0a
> Author: Johannes Berg <[email protected]>
> Date: Fri Nov 28 12:14:06 2014 +0100
>
> cfg80211: make WEXT compatibility unselectable

I think this needs to be reverted.

--
Jiri Kosina
SUSE Labs

2014-12-30 20:28:50

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 2014-12-30 at 16:21 +0100, Jiri Kosina wrote:
> On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote:
>
> > > > So why do you used them?
> > > > They have been deprecated for a couple of years now. You should be
> > > > using nl80211 based tools such as iw.
> > >
> > > A couple of years is not very long where userspace is concerned.
> > >
> > Well - the decently new wireless tools do talk nl80211.
>
> With 3.18-rc5, I get this:
>
> # iwconfig --version
> iwconfig Wireless-Tools version 30
> Compatible with Wireless Extension v11 to v22.
>
> Kernel Currently compiled with Wireless Extension v22.
>
> wlan0 Recommend Wireless Extension v21 or later,
> Currently compiled with Wireless Extension v22.
>
>
> With 3.19-rc, I get (with the same userspace) this:
>
> # iwconfig --version
> iwconfig Wireless-Tools version 30
> Compatible with Wireless Extension v11 to v22.
>
> Cannot read /proc/net/wireless
>
> And nothing else (iwlist, etc) works either. This is with
>
> # rpm -qi wireless-tools | grep Ver
> Version : 30.pre9
>
> from openSUSE 13.2. That's not decently new enough?
>

You should also have the iw tool which will provide all you need
using the nl80211 interface which is now the preferred interface.

> > You can still enable it (CFG80211_WEXT).
> > It has been disabled by:
> >
> > commit 24a0aa212ee2dbe44360288684478d76a8e20a0a
> > Author: Johannes Berg <[email protected]>
> > Date: Fri Nov 28 12:14:06 2014 +0100
> >
> > cfg80211: make WEXT compatibility unselectable
>
> I think this needs to be reverted.
>

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?

2014-12-30 20:41:46

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 30 Dec 2014, Grumbach, Emmanuel wrote:

> You should also have the iw tool which will provide all you need
> using the nl80211 interface which is now the preferred interface.

There indeed is an iw tool.

The thing is really as simple as -- userspace which is calling other
wireless-utils directly (such as, but absolutely not limited to, wicd),
will completely stop working after commit 24a0aa212e.

I am still convinced that 24a0aa212e needs to be reverted, and compat
layer maintained for *much* longer than 2 years.

If wireless maintainers think otherwise, I'll send a revert request to
Linus for consideration.

Thanks,

--
Jiri Kosina
SUSE Labs

2014-12-30 21:23:30

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, Dec 30, 2014 at 09:41:41PM +0100, Jiri Kosina wrote:
> If wireless maintainers think otherwise, I'll send a revert request to
> Linus for consideration.

I wonder if the reaction would be like this one:

https://lkml.org/lkml/2012/12/23/75

:-)

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

2014-12-30 22:35:50

by Larry Finger

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On 12/30/2014 03:23 PM, Borislav Petkov wrote:
> On Tue, Dec 30, 2014 at 09:41:41PM +0100, Jiri Kosina wrote:
>> If wireless maintainers think otherwise, I'll send a revert request to
>> Linus for consideration.
>
> I wonder if the reaction would be like this one:
>
> https://lkml.org/lkml/2012/12/23/75
>
> :-)

It would be a little like that.

One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made it
impossible to select the IPW2200. The patch to allow selecting the IPW2200,
which automatically selects CFG80211_WEXT has been added to wireless-drivers,
but it has not yet made it to mainline. Once it does, then choosing to build the
IPW2200 will provide a workaround.

In my opinion, the need for the IPW2200 to have CFG80211_WEXT means that the
original commit will likely be reverted, but your voice will help.

I use openSUSE 13.2, but I control my wireless with NetworkManager. For that
reason, this is a non-issue for me.

Larry

2014-12-30 22:42:52

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Tue, 30 Dec 2014, Larry Finger wrote:

> > > If wireless maintainers think otherwise, I'll send a revert request to
> > > Linus for consideration.
> >
> > I wonder if the reaction would be like this one:
> >
> > https://lkml.org/lkml/2012/12/23/75
> >
> > :-)
>
> It would be a little like that.
>
> One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made it
> impossible to select the IPW2200. The patch to allow selecting the IPW2200,
> which automatically selects CFG80211_WEXT has been added to wireless-drivers,
> but it has not yet made it to mainline. Once it does, then choosing to build
> the IPW2200 will provide a workaround.
>
> In my opinion, the need for the IPW2200 to have CFG80211_WEXT means that the
> original commit will likely be reverted, but your voice will help.

Ok, thanks a lot for another datapoint. I am sending revert patch to Linus
tonight.

--
Jiri Kosina
SUSE Labs

2014-12-30 22:52:25

[permalink] [raw]

Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.

It's causing severe userspace breakage. Namely, all the utilities
from wireless-utils which are relying on CONFIG_WEXT (which means
tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
is a 'iw' utility in newer wireless-tools, which is supposed to be
a replacement for all the "deprecated" binaries, but it's far away
from being massively adopted.

Please see [1] for example of the userspace breakage this is causing.

In addition to that, Larry Finger reports [2] that this patch is also
causing ipw2200 driver being impossible to build.

To me this clearly shows that CONFIG_WEXT is far, far away from being
"deprecated enough" to be removed.

[1] http://thread.gmane.org/gmane.linux.kernel/1857010
[2] http://thread.gmane.org/gmane.linux.network/343688

Signed-off-by: Jiri Kosina <[email protected]>
---
net/wireless/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 22ba971..29c8675 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
Most distributions have a CRDA package. So if unsure, say N.

config CFG80211_WEXT
- bool
+ bool "cfg80211 wireless extensions compatibility"
depends on CFG80211
select WEXT_CORE
help
--
Jiri Kosina
SUSE Labs

2014-12-31 07:44:22

[permalink] [raw]

Subject: RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

> Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
>
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>
> It's causing severe userspace breakage. Namely, all the utilities from
> wireless-utils which are relying on CONFIG_WEXT (which means tools like
> 'iwconfig', 'iwlist', etc) are not working anymore. There is a 'iw' utility in
> newer wireless-tools, which is supposed to be a replacement for all the
> "deprecated" binaries, but it's far away from being massively adopted.
>
> Please see [1] for example of the userspace breakage this is causing.
>
> In addition to that, Larry Finger reports [2] that this patch is also causing
> ipw2200 driver being impossible to build.
>
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.
>
> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688
>
> Signed-off-by: Jiri Kosina <[email protected]>

Wait. I don't want to discuss the userspace API deprecation here but
I do think that this patch should be applied to the proper tree if at all.
The proper tree is mac80211.git. Now you are unhappy with what happens
there and want to escalate - fine. But then, please do so following the
natural hierarchy of the trees: net.git. Then mac80211.git's maintainer
(Johannes) will be able to sync with your change more easily.
Johannes doesn't need me as an advocate, but I feel that reverting a
mac80211 patch in linux.git while we are only in -rc2 while everybody
is on holiday leave is a bit unfair.

> ---
> net/wireless/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
> 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> Most distributions have a CRDA package. So if unsure, say N.
>
> config CFG80211_WEXT
> - bool
> + bool "cfg80211 wireless extensions compatibility"
> depends on CFG80211
> select WEXT_CORE
> help
> --
> Jiri Kosina
> SUSE Labs

2014-12-31 07:50:26

[permalink] [raw]

Subject: RE: iwlwifi-driver card doesn't work with 3.19-rc2+

>
> On Tue, 30 Dec 2014, Larry Finger wrote:
>
> > > > If wireless maintainers think otherwise, I'll send a revert
> > > > request to Linus for consideration.
> > >
> > > I wonder if the reaction would be like this one:
> > >
> > > https://lkml.org/lkml/2012/12/23/75
> > >
> > > :-)
> >
> > It would be a little like that.
> >
> > One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> > 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made
> > it impossible to select the IPW2200. The patch to allow selecting the
> > IPW2200, which automatically selects CFG80211_WEXT has been added to
> > wireless-drivers, but it has not yet made it to mainline. Once it
> > does, then choosing to build the IPW2200 will provide a workaround.
> >
> > In my opinion, the need for the IPW2200 to have CFG80211_WEXT means
> > that the original commit will likely be reverted, but your voice will help.
>
> Ok, thanks a lot for another datapoint. I am sending revert patch to Linus
> tonight.
>
I don't see this as another datapoint. All it means is that there are ancient drivers
that won't work at all with newer tools and that are taken into consideration while
trying to deprecate an API.
Now - basically all your argument is on Johannes's comment: "deprecated enough".
I think we have a chicken and egg problem here. We can't break things towards userland.
Good. But we do want to deprecate this API because lots of valid purely technical reasons.
Unfortunately, I don't see what we could do to send a strong signal to userspace tools developers
to have them work / plan a move to a modern API.

2014-12-31 08:03:30

by Sujith Manoharan

[permalink] [raw]

Subject: RE: iwlwifi-driver card doesn't work with 3.19-rc2+

Grumbach, Emmanuel wrote:
> I don't see this as another datapoint. All it means is that there are ancient
> drivers that won't work at all with newer tools and that are taken into
> consideration while trying to deprecate an API.

Not just drivers, tools and applications too.

I don't think we can ever lose the WEXT baggage since there will probably be
tools that will never migrate to nl80211. But, we can direct to /dev/null all
kernel bugs that are related to WEXT. :-)

Sujith

2014-12-31 11:09:15

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/30/14 23:52, Jiri Kosina wrote:
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>
> It's causing severe userspace breakage. Namely, all the utilities
> from wireless-utils which are relying on CONFIG_WEXT (which means
> tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
> is a 'iw' utility in newer wireless-tools, which is supposed to be
> a replacement for all the "deprecated" binaries, but it's far away
> from being massively adopted.
>
> Please see [1] for example of the userspace breakage this is causing.
>
> In addition to that, Larry Finger reports [2] that this patch is also
> causing ipw2200 driver being impossible to build.
>
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.

Hi Jiri,

You mentioned in the discussion and I quote: "*If* wireless maintainers
think otherwise, I'll send a revert request to Linus for
consideration.". However, you did not wait for any response from the
wireless maintainers nor from the author of the patch you are reverting.
Seems like an overreaction to me though personally I do not disgree with
the revert itself.

Regards,
Arend

> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688
>
> Signed-off-by: Jiri Kosina<[email protected]>
> ---
> net/wireless/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> Most distributions have a CRDA package. So if unsure, say N.
>
> config CFG80211_WEXT
> - bool
> + bool "cfg80211 wireless extensions compatibility"
> depends on CFG80211
> select WEXT_CORE
> help

2014-12-31 11:11:02

[permalink] [raw]

Subject: RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

> On 12/30/14 23:52, Jiri Kosina wrote:
> > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
> >
> > It's causing severe userspace breakage. Namely, all the utilities from
> > wireless-utils which are relying on CONFIG_WEXT (which means tools
> > like 'iwconfig', 'iwlist', etc) are not working anymore. There is a
> > 'iw' utility in newer wireless-tools, which is supposed to be a
> > replacement for all the "deprecated" binaries, but it's far away from
> > being massively adopted.
> >
> > Please see [1] for example of the userspace breakage this is causing.
> >
> > In addition to that, Larry Finger reports [2] that this patch is also
> > causing ipw2200 driver being impossible to build.
> >
> > To me this clearly shows that CONFIG_WEXT is far, far away from being
> > "deprecated enough" to be removed.
>
> Hi Jiri,
>
> You mentioned in the discussion and I quote: "*If* wireless maintainers think
> otherwise, I'll send a revert request to Linus for consideration.". However,
> you did not wait for any response from the wireless maintainers nor from the
> author of the patch you are reverting.
> Seems like an overreaction to me though personally I do not disgree with the
> revert itself.

Not to mention the patch has already been applied on Linus's tree...

>
> Regards,
> Arend
>
> > [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> > [2] http://thread.gmane.org/gmane.linux.network/343688
> >
> > Signed-off-by: Jiri Kosina<[email protected]>
> > ---
> > net/wireless/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
> > 22ba971..29c8675 100644
> > --- a/net/wireless/Kconfig
> > +++ b/net/wireless/Kconfig
> > @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> > Most distributions have a CRDA package. So if unsure, say N.
> >
> > config CFG80211_WEXT
> > - bool
> > + bool "cfg80211 wireless extensions compatibility"
> > depends on CFG80211
> > select WEXT_CORE
> > help

2014-12-31 11:45:59

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/14 12:10, Grumbach, Emmanuel wrote:
>> On 12/30/14 23:52, Jiri Kosina wrote:
>>> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>>>
>>> It's causing severe userspace breakage. Namely, all the utilities from
>>> wireless-utils which are relying on CONFIG_WEXT (which means tools
>>> like 'iwconfig', 'iwlist', etc) are not working anymore. There is a
>>> 'iw' utility in newer wireless-tools, which is supposed to be a
>>> replacement for all the "deprecated" binaries, but it's far away from
>>> being massively adopted.
>>>
>>> Please see [1] for example of the userspace breakage this is causing.
>>>
>>> In addition to that, Larry Finger reports [2] that this patch is also
>>> causing ipw2200 driver being impossible to build.
>>>
>>> To me this clearly shows that CONFIG_WEXT is far, far away from being
>>> "deprecated enough" to be removed.
>>
>> Hi Jiri,
>>
>> You mentioned in the discussion and I quote: "*If* wireless maintainers think
>> otherwise, I'll send a revert request to Linus for consideration.". However,
>> you did not wait for any response from the wireless maintainers nor from the
>> author of the patch you are reverting.
>> Seems like an overreaction to me though personally I do not disgree with the
>> revert itself.
>
> Not to mention the patch has already been applied on Linus's tree...

Water under the bridge. The thing with WEXT is that it will stay as is.
So if tools like wicd want to support new features like P2P it will need
to make the switch. I checked out wicd repo and found a number of
iwconfig calls and they kick off wpa_supplicant with wext driver.

With libnl python support wicd could use nl80211 directly avoiding
screen-scraping iw output, but it seems not included in distros.

Regards,
Arend

>>
>> Regards,
>> Arend
>>
>>> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
>>> [2] http://thread.gmane.org/gmane.linux.network/343688
>>>
>>> Signed-off-by: Jiri Kosina<[email protected]>
>>> ---
>>> net/wireless/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index
>>> 22ba971..29c8675 100644
>>> --- a/net/wireless/Kconfig
>>> +++ b/net/wireless/Kconfig
>>> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
>>> Most distributions have a CRDA package. So if unsure, say N.
>>>
>>> config CFG80211_WEXT
>>> - bool
>>> + bool "cfg80211 wireless extensions compatibility"
>>> depends on CFG80211
>>> select WEXT_CORE
>>> help
>

2014-12-31 13:10:30

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, 31 Dec 2014, Arend van Spriel wrote:

> You mentioned in the discussion and I quote: "*If* wireless maintainers
> think otherwise, I'll send a revert request to Linus for
> consideration.". However, you did not wait for any response from the
> wireless maintainers nor from the author of the patch you are reverting.
> Seems like an overreaction to me though personally I do not disgree with
> the revert itself.

My understanding from the whole thread was that Emmanuel disagrees with
the revert, and I consider Emmanuel to definitely belong to the "wireless
maintainers" group. If my understanding was wrong on this, sorry for that.

One way or another, the revert really is a-must-have, as it causes visible
userspace regressions. I am really surprised that it's causing so lively
discussion and doubts.

--
Jiri Kosina
SUSE Labs

2014-12-31 13:27:01

[permalink] [raw]

Subject: RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

>
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>
> > You mentioned in the discussion and I quote: "*If* wireless
> > maintainers think otherwise, I'll send a revert request to Linus for
> > consideration.". However, you did not wait for any response from the
> > wireless maintainers nor from the author of the patch you are reverting.
> > Seems like an overreaction to me though personally I do not disgree
> > with the revert itself.
>
> My understanding from the whole thread was that Emmanuel disagrees with
> the revert, and I consider Emmanuel to definitely belong to the "wireless
> maintainers" group. If my understanding was wrong on this, sorry for that.

You understanding is wrong. This patch has an author and you could I didn't
sign-off the patch which is an obvious indication I am not a "wireless maintainer".
You didn't even make the minimal effort to check how this patch should be properly
routed.

Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
the userland developers that an API will be deprecated at some point. I haven't seen
any response / suggestion from you on that.

>
> One way or another, the revert really is a-must-have, as it causes visible
> userspace regressions. I am really surprised that it's causing so lively
> discussion and doubts.
>
> --
> Jiri Kosina
> SUSE Labs

2014-12-31 13:49:11

by Peter Hurley

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
>>
>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>
>>> You mentioned in the discussion and I quote: "*If* wireless
>>> maintainers think otherwise, I'll send a revert request to Linus for
>>> consideration.". However, you did not wait for any response from the
>>> wireless maintainers nor from the author of the patch you are reverting.
>>> Seems like an overreaction to me though personally I do not disgree
>>> with the revert itself.
>>
>> My understanding from the whole thread was that Emmanuel disagrees with
>> the revert, and I consider Emmanuel to definitely belong to the "wireless
>> maintainers" group. If my understanding was wrong on this, sorry for that.
>
> You understanding is wrong. This patch has an author and you could I didn't
> sign-off the patch which is an obvious indication I am not a "wireless maintainer".
> You didn't even make the minimal effort to check how this patch should be properly
> routed.
>
> Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
> the userland developers that an API will be deprecated at some point. I haven't seen
> any response / suggestion from you on that.

pr_notice_once("WEXT compatibility has been deprecated since _____" \
" Upgrade your userspace tools to nl80211!\n");

2014-12-31 13:54:53

[permalink] [raw]

Subject: Re: iwlwifi-driver card doesn't work with 3.19-rc2+

On Wed, Dec 31, 2014 at 07:50:19AM +0000, Grumbach, Emmanuel wrote:
> Now - basically all your argument is on Johannes's comment:
> "deprecated enough". I think we have a chicken and egg problem here.
> We can't break things towards userland. Good. But we do want to
> deprecate this API because lots of valid purely technical reasons.
> Unfortunately, I don't see what we could do to send a strong signal to
> userspace tools developers to have them work / plan a move to a modern
> API.

I don't see what all the fuss is all about. If you're still unsure, go
read Linus' message once more. You're absolutely not allowed to break
userspace. Fullstop. No ifs and buts and whatever.

Everything extra you wanna do is probably fine. You can go talk to
userspace tools maintainers using the deprecated API, you can go and fix
it yourself, and so on and so on...

And giving Jiri hard time for "bypassing" maintainers for something
which is clearly a no-no and has to be reverted the moment it hits
mainline shows yet again you haven't really understood the rule yet:

There is no breaking of userspace. Fullstop.

Things like that get reverted ASAP. No "it needs to go through my tree",
"I'm not sure, blabalba" ...

So instead of giving him hard time, say "thank you for sending the
revert and thank you for helping us maintainers". Now, before you say
something, remember this: there is no breaking of userspace!

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

2014-12-31 14:08:02

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, 31 Dec 2014, Arend van Spriel wrote:

> The thing with WEXT is that it will stay as is. So if tools like wicd
> want to support new features like P2P it will need to make the switch. I
> checked out wicd repo and found a number of iwconfig calls and they kick
> off wpa_supplicant with wext driver.

Unfortunately this is by no means just about wicd. I have already received
a few off-list mails from people who were wondering why their home-made
scripts / tools, which are running 'iwconfig' directly suddenly stopped to
work, and that it was indeed fallout of WEXT going away. Given the very
short time this has been in mainline, you can probably imagine the
fireworks once this appears in major release.

--
Jiri Kosina
SUSE Labs

2014-12-31 14:41:16

by Julian Calaby

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

Hi,

On Thu, Jan 1, 2015 at 12:49 AM, Peter Hurley <[email protected]> wrote:
> On 12/31/2014 08:26 AM, Grumbach, Emmanuel wrote:
>>>
>>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>>
>>>> You mentioned in the discussion and I quote: "*If* wireless
>>>> maintainers think otherwise, I'll send a revert request to Linus for
>>>> consideration.". However, you did not wait for any response from the
>>>> wireless maintainers nor from the author of the patch you are reverting.
>>>> Seems like an overreaction to me though personally I do not disgree
>>>> with the revert itself.
>>>
>>> My understanding from the whole thread was that Emmanuel disagrees with
>>> the revert, and I consider Emmanuel to definitely belong to the "wireless
>>> maintainers" group. If my understanding was wrong on this, sorry for that.
>>
>> You understanding is wrong. This patch has an author and you could I didn't
>> sign-off the patch which is an obvious indication I am not a "wireless maintainer".
>> You didn't even make the minimal effort to check how this patch should be properly
>> routed.
>>
>> Regardless of all this, I didn't say I disagree, I said that we need to find a way to signal
>> the userland developers that an API will be deprecated at some point. I haven't seen
>> any response / suggestion from you on that.
>
> pr_notice_once("WEXT compatibility has been deprecated since _____" \
> " Upgrade your userspace tools to nl80211!\n");

Sadly, nobody will read that. It needs to be at least an error,
possibly with a big splat to scare people.

Maybe using one of WARN()'s siblings instead.

Thanks,

--
Julian Calaby

Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/

2014-12-31 14:46:21

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Thu, Jan 01, 2015 at 01:40:53AM +1100, Julian Calaby wrote:
> Sadly, nobody will read that. It needs to be at least an error,
> possibly with a big splat to scare people.
>
> Maybe using one of WARN()'s siblings instead.

And that opens a lot of useless bugzillas...

The right thing to do is go talk to the maintainers of the userspace
tools or send patches.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

2014-12-31 15:02:30

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/14 15:07, Jiri Kosina wrote:
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>
>> The thing with WEXT is that it will stay as is. So if tools like wicd
>> want to support new features like P2P it will need to make the switch. I
>> checked out wicd repo and found a number of iwconfig calls and they kick
>> off wpa_supplicant with wext driver.
>
> Unfortunately this is by no means just about wicd. I have already received
> a few off-list mails from people who were wondering why their home-made
> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
> work, and that it was indeed fallout of WEXT going away. Given the very
> short time this has been in mainline, you can probably imagine the
> fireworks once this appears in major release.

It is unfortunately indeed. I think iwconfig and friends will never go
away although iw is a better alternative, simply because people don't
like to change their home-made scripts/tools. WIRELESS_EXT actually is
largely, but not entirely, gone in upstream drivers and what we are
talking about here is CFG80211_WEXT which allows WEXT userspace to
interact with cfg80211-based drivers through a compatibility layer.

Regards,
Arend

2014-12-31 15:03:38

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Thu, 1 Jan 2015, Julian Calaby wrote:

> The point is that WEXT has been depreciated for _years_. Nobody seems
> to have listened. Yes, talking to maintainers will get the last
> holdouts of the "big" tools (e.g. wicd) to fix them, but it's not
> going to change all the people out there with hacked together
> home-grown setups.

Exactly. So why not work with whoever maintains iwconfig and friends, so
that they are turned into functionally equivalent wrappers around iw? Only
then it seems to make sense to start any kind of depreciation.

--
Jiri Kosina
SUSE Labs

2014-12-31 15:05:32

by Julian Calaby

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

Hi Borislav,

On Thu, Jan 1, 2015 at 1:46 AM, Borislav Petkov <[email protected]> wrote:
> On Thu, Jan 01, 2015 at 01:40:53AM +1100, Julian Calaby wrote:
>> Sadly, nobody will read that. It needs to be at least an error,
>> possibly with a big splat to scare people.
>>
>> Maybe using one of WARN()'s siblings instead.
>
> And that opens a lot of useless bugzillas...
>
> The right thing to do is go talk to the maintainers of the userspace
> tools or send patches.

The point is that WEXT has been depreciated for _years_. Nobody seems
to have listened. Yes, talking to maintainers will get the last
holdouts of the "big" tools (e.g. wicd) to fix them, but it's not
going to change all the people out there with hacked together
home-grown setups.

Yes, a full WARN() will end up with loads of duplicated bugzillas -
and I wish I had the time to volunteer to close every last one with
"upgrade your userspace to use nl80211 / iw" - but I feel that
speaking quietly hasn't worked: maybe now we need to yell.

Thanks,

--
Julian Calaby

Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/

2014-12-31 15:11:40

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Thu, Jan 01, 2015 at 01:56:54AM +1100, Julian Calaby wrote:
> The point is that WEXT has been depreciated for _years_. Nobody
> seems to have listened. Yes, talking to maintainers will get the
> last holdouts of the "big" tools (e.g. wicd) to fix them, but it's
> not going to change all the people out there with hacked together
> home-grown setups.

That's fine - you can fix the major tools first and then take a look at
the home-grown fun later.

> Yes, a full WARN() will end up with loads of duplicated bugzillas -
> and I wish I had the time to volunteer to close every last one with
> "upgrade your userspace to use nl80211 / iw" - but I feel that
> speaking quietly hasn't worked: maybe now we need to yell.

This goes to show once again how hard it is to design a userspace
interface properly and how hard it is to change it once it gets exposed.

But yeah, screaming or not screaming, you will have to support it anyway
as long as there are tools using it. This is why I think the proper and
maybe faster way to address the situation is to go fix userspace tools
instead of issuing warnings. People never look at those as long as it
works, in my experience.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

2014-12-31 15:21:14

by Andreas Hartmann

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

Jiri Kosina wrote:
> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>
>> The thing with WEXT is that it will stay as is. So if tools like wicd
>> want to support new features like P2P it will need to make the switch. I
>> checked out wicd repo and found a number of iwconfig calls and they kick
>> off wpa_supplicant with wext driver.
>
> Unfortunately this is by no means just about wicd. I have already received
> a few off-list mails from people who were wondering why their home-made
> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
> work, and that it was indeed fallout of WEXT going away. Given the very
> short time this has been in mainline, you can probably imagine the
> fireworks once this appears in major release.

It is not just the userspace tools (I prefer them, too), which need
wext, but a lot of drivers, too, such as Mediathek drivers e.g. which
perform *much* better compared to rt2x00, especially concerning USB
chips like the one used by Linksys AE3000 (3x3 Mimo)
(https://wikidevi.com/wiki/Linksys_AE3000), which achieves average
throughputs around 14 MB/s *average* with scp of big (> 10 GB) crypted
files even through reinforced-concrete floor(!) - rt2x00 is *far* away
of providing such a performance.

Next bad point of rt2x00 e.g. is the huge CPU overhead - compare
rt5572sta on Raspi with rt2x00 running netperf and you will see the huge
problem of rt2x00 (which is covered on x86 by mostly oversized multi
core CPUs).

Another big advantage of rt5572sta is: it is *stable* over a lot of
kernel versions (as long as the kernel didn't break interfaces - but
there are patches to catch them).

Even ath9k, which usually is a really fine driver, is broken on some
kernel versions (link and throughput is not stable - my use case depends
*heavily* on very high and longterm stable throughput). That's why I'm
using a VM for my ath9k-device to be independent of these quality
problems of mac80211 (or maybe ath9k - don't know) over different kernel
versions.

All in all:
If you want to get rid of wext, you still have to go a *very* long way
to get the same *stable* and high throughput quality with *all* chips
depending on mac80211 and not just a few flagship drivers like Atheros.

Kind regards,
Andreas Hartmann

2014-12-31 16:43:15

by Paul Bolle

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Tue, 2014-12-30 at 23:52 +0100, Jiri Kosina wrote:
> This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a.
>
> It's causing severe userspace breakage. Namely, all the utilities
> from wireless-utils which are relying on CONFIG_WEXT (which means
> tools like 'iwconfig', 'iwlist', etc) are not working anymore. There
> is a 'iw' utility in newer wireless-tools, which is supposed to be
> a replacement for all the "deprecated" binaries, but it's far away
> from being massively adopted.
>
> Please see [1] for example of the userspace breakage this is causing.
>
> In addition to that, Larry Finger reports [2] that this patch is also
> causing ipw2200 driver being impossible to build.
>
> To me this clearly shows that CONFIG_WEXT is far, far away from being
> "deprecated enough" to be removed.
>
> [1] http://thread.gmane.org/gmane.linux.kernel/1857010
> [2] http://thread.gmane.org/gmane.linux.network/343688

So [2] already entered mainline as commit dddd60220f41 ("ipw2200: select
CFG80211_WEXT"). As this revert has now been applied, I think my patch
should now be reverted too. But I don't think it's a good idea to submit
a patch, however trivial, in the last hours before new year. So I'll
have a look into this in the first days of next year.

> Signed-off-by: Jiri Kosina <[email protected]>
> ---
> net/wireless/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 22ba971..29c8675 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB
> Most distributions have a CRDA package. So if unsure, say N.
>
> config CFG80211_WEXT
> - bool
> + bool "cfg80211 wireless extensions compatibility"
> depends on CFG80211
> select WEXT_CORE
> help

Paul Bolle

2014-12-31 17:31:31

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote:
>
> It is unfortunately indeed. I think iwconfig and friends will never go away
> although iw is a better alternative, simply because people don't like to
> change their home-made scripts/tools. WIRELESS_EXT actually is largely, but
> not entirely, gone in upstream drivers and what we are talking about here is
> CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based
> drivers through a compatibility layer.

Most poeple are still using "route" and "ifconfig" instead of "ip".
Deal with it. Personally, I find it much easier to use the existing
commands instead of figuring all of the various subcommands, and the
options to the subcommands to commands like "ip" and "iw". At least
"ip help route" will give me all of the options to "ip route", where
as "iw help phy" doesn't tell give me the options; instead I have to
paw through 300 lines of "iw help" in order to find the command I
need. So having a better user interface / help system so people can
better understand how to use iw would be a great step forward.

Better yet, why not hack into the "iw" command backwards compatibility
so that if argv[0] is "iwlist" or "iwconfig", it provides the limited
subset compatibility to the legacy commands. Then all you need to do
is to convince the distributions to set up the packaging rules so that
"iw" conflicts with wireless-tools, and you will be able to get
everyone switched over to iw after at least seven years.

Note that I said *seven* years --- there are people who try to use an
enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace,
with a newer kernel, and and if said users notice, and complain, Linus
*will* revert the commit. (Note that I've worked at more than one
company where I was forced to use an older Ubuntu LTS or RHEL distro
if I wanted to connect to the intranet, and I was using bleeding edge
kernels --- and if anything like that had broken, I would have
complained directly to Linus, cc'ing the patch author and the wireless
maintainers with the revert. And while I fortunately am not trying to
do upstream development with a stable distro, be sure there are other
such folks around who have to live with similar restrictions.)

- Ted

P.S. If you really think it's evil that users use the
simpler-to-understand iwconfig/iwlist interface over the iw command
line interface, if you provide full backwards compatibility for the
iwconfig/iwlist commands so you can "take over" from wireless-tools,
you could even have a mode which, in addition to doing what the user
wants, prints a "by the way, here's the equivalent if you want to use
the iw command instead". I don't see the reason of allowing users to
continue to use iwconfig and iwlist, though --- face it, route and
ifconfig are going to be around for a long time; why not let users use
iwconfig and iwlist if it's sufficient for their needs?

2014-12-31 17:44:25

by Linus Torvalds

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o <[email protected]> wrote:
>
> Most poeple are still using "route" and "ifconfig" instead of "ip".
> Deal with it.

Indeed. This whole "let's throw out the old and broken" stuff is a disease.

It would have been much better (and it's still an option, as Ted
points out) for the new commands to provide compatibility with what
users - and scripts - have been doing for ages with the old ones.

As it is, this inability for the new tools to just do what the old
tools did clearly just means that not just the old tools, but all the
old infrastructure, will need to be around for years to come.

Thinking you can just start from a clean slate is naive, bordering on
stupid. "New and improved" is only really improved if it also takes
backwards compatibility into account, rather than saying "now
everybody must do things the new and improved - and different - way"

We've succeeded in getting rid of some old interfaces in the kernel,
but it has usually been for some *really* esoteric stuff that nobody
does by hand. And even then it has generally been an uphill battle,
and in most cases we've ended up having the rule that new capabilities
absolutely *have* to be a superset of the old, and we continue to
support the old model using the new code.

It's entirely possible that we might be able to cut down on the WEXT
support a tiny bit by slowly removing some parts of it that nobody
uses and depends on, but the whole "let's just make it a non-option"
was clearly just a drug-fueled bad fantasy.

Linus

2014-12-31 19:48:31

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/14 16:14, Andreas Hartmann wrote:
> Jiri Kosina wrote:
>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>
>>> The thing with WEXT is that it will stay as is. So if tools like wicd
>>> want to support new features like P2P it will need to make the switch. I
>>> checked out wicd repo and found a number of iwconfig calls and they kick
>>> off wpa_supplicant with wext driver.
>>
>> Unfortunately this is by no means just about wicd. I have already received
>> a few off-list mails from people who were wondering why their home-made
>> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
>> work, and that it was indeed fallout of WEXT going away. Given the very
>> short time this has been in mainline, you can probably imagine the
>> fireworks once this appears in major release.
>
> It is not just the userspace tools (I prefer them, too), which need
> wext, but a lot of drivers, too, such as Mediathek drivers e.g. which
> perform *much* better compared to rt2x00, especially concerning USB
> chips like the one used by Linksys AE3000 (3x3 Mimo)
> (https://wikidevi.com/wiki/Linksys_AE3000), which achieves average
> throughputs around 14 MB/s *average* with scp of big (> 10 GB) crypted
> files even through reinforced-concrete floor(!) - rt2x00 is *far* away
> of providing such a performance.
>
> Next bad point of rt2x00 e.g. is the huge CPU overhead - compare
> rt5572sta on Raspi with rt2x00 running netperf and you will see the huge
> problem of rt2x00 (which is covered on x86 by mostly oversized multi
> core CPUs).
>
> Another big advantage of rt5572sta is: it is *stable* over a lot of
> kernel versions (as long as the kernel didn't break interfaces - but
> there are patches to catch them).
>
> Even ath9k, which usually is a really fine driver, is broken on some
> kernel versions (link and throughput is not stable - my use case depends
> *heavily* on very high and longterm stable throughput). That's why I'm
> using a VM for my ath9k-device to be independent of these quality
> problems of mac80211 (or maybe ath9k - don't know) over different kernel
> versions.
>
>
> All in all:
> If you want to get rid of wext, you still have to go a *very* long way
> to get the same *stable* and high throughput quality with *all* chips
> depending on mac80211 and not just a few flagship drivers like Atheros.

Hi Andreas,

That's a nice list of unrelated stuff. This has all nothing to do with
WEXT. Actually, you can build rt5572sta with cfg80211 support
(RT_CFG80211_SUPPORT). This thread is about the configuration API and
not about driver performance.

Regards,
Arend

> Kind regards,
> Andreas Hartmann
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2014-12-31 20:32:19

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/14 18:31, Theodore Ts'o wrote:
> On Wed, Dec 31, 2014 at 04:02:24PM +0100, Arend van Spriel wrote:
>>
>> It is unfortunately indeed. I think iwconfig and friends will never go away
>> although iw is a better alternative, simply because people don't like to
>> change their home-made scripts/tools. WIRELESS_EXT actually is largely, but
>> not entirely, gone in upstream drivers and what we are talking about here is
>> CFG80211_WEXT which allows WEXT userspace to interact with cfg80211-based
>> drivers through a compatibility layer.
>
> Most poeple are still using "route" and "ifconfig" instead of "ip".
> Deal with it. Personally, I find it much easier to use the existing
> commands instead of figuring all of the various subcommands, and the
> options to the subcommands to commands like "ip" and "iw". At least
> "ip help route" will give me all of the options to "ip route", where
> as "iw help phy" doesn't tell give me the options; instead I have to
> paw through 300 lines of "iw help" in order to find the command I
> need. So having a better user interface / help system so people can
> better understand how to use iw would be a great step forward.

Agree. I can't even recall using "ip" ever. iw help system does provide
command specific help. The phy keyword is both a command and a selector
key, which I realize is confusing to the user, eg. 'iw help info' does
provide help for the 'info' subcommand.

> Better yet, why not hack into the "iw" command backwards compatibility
> so that if argv[0] is "iwlist" or "iwconfig", it provides the limited
> subset compatibility to the legacy commands. Then all you need to do
> is to convince the distributions to set up the packaging rules so that
> "iw" conflicts with wireless-tools, and you will be able to get
> everyone switched over to iw after at least seven years.

Thanks. If there are still drivers, upstream or out-of-tree, providing
only WEXT API this will not work unless iwconfig/iwlist can distinguish
those from cfg80211-based drivers (which is possible) and fallback to
WEXT ioctl syscalls. Just not sure if it is worth the effort. As you
stated below, it does not seem "evil" to retain WEXT if that is
providing users what they need.

Regards,
Arend

> Note that I said *seven* years --- there are people who try to use an
> enterprise kernel, or an older Debian Stable or Ubuntu LTS userspace,
> with a newer kernel, and and if said users notice, and complain, Linus
> *will* revert the commit. (Note that I've worked at more than one
> company where I was forced to use an older Ubuntu LTS or RHEL distro
> if I wanted to connect to the intranet, and I was using bleeding edge
> kernels --- and if anything like that had broken, I would have
> complained directly to Linus, cc'ing the patch author and the wireless
> maintainers with the revert. And while I fortunately am not trying to
> do upstream development with a stable distro, be sure there are other
> such folks around who have to live with similar restrictions.)
>
> - Ted
>
> P.S. If you really think it's evil that users use the
> simpler-to-understand iwconfig/iwlist interface over the iw command
> line interface, if you provide full backwards compatibility for the
> iwconfig/iwlist commands so you can "take over" from wireless-tools,
> you could even have a mode which, in addition to doing what the user
> wants, prints a "by the way, here's the equivalent if you want to use
> the iw command instead". I don't see the reason of allowing users to
> continue to use iwconfig and iwlist, though --- face it, route and
> ifconfig are going to be around for a long time; why not let users use
> iwconfig and iwlist if it's sufficient for their needs?

2014-12-31 21:44:36

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote:
>
> Agree. I can't even recall using "ip" ever. iw help system does provide
> command specific help. The phy keyword is both a command and a selector key,
> which I realize is confusing to the user, eg. 'iw help info' does provide
> help for the 'info' subcommand.

Yeah, the confusing part is that "ip" tends to use "verb object"
scheme, which is consistent with the Cisco IOS command set it was
trying to emulate. So for ip, you do something like

ip link info eth0

Where as for "iw" it's almost exactly backwards, i.e.:

iw wlan0 info

It's actually rather unfortunate that there is no consistency between
many of these tools, for example:

ethtool --show-features eth0

If we were going to create a new interface, wouldn't be nice if we
could have some kind of consistency? Sigh; oh well, water under the
bridge at this point.

> Thanks. If there are still drivers, upstream or out-of-tree, providing only
> WEXT API this will not work unless iwconfig/iwlist can distinguish those
> from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl
> syscalls. Just not sure if it is worth the effort. As you stated below, it
> does not seem "evil" to retain WEXT if that is providing users what they
> need.

Is it really that much effort? Unless there is some license
incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already
there in the wireless-tools source. It would just be a matter of
trying the new ioctls first, and then falling back to the WEXT ones if
needed, right?

Cheers,

- Ted

2014-12-31 21:58:02

by Linus Torvalds

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o <[email protected]> wrote:
>
> Yeah, the confusing part is that "ip" tends to use "verb object"
> scheme, which is consistent with the Cisco IOS command set it was
> trying to emulate.

Side note: does anybody think that was really a good idea to begin
with? I mean, Cisco iOS is just _soooo_ universally loved, right?

And yeah, I refuse to use "ip link" or other insane commands. Let's
face it, "ifconfig" and "route" are perfectly fine commands, and a
whole lot less confusing than "ip" with random crap after it. I'm
really not seeing why that "ip" command was seen as an improvement.

(Ok, "ip route" isn't any more complex than "route", but "ip link"
sure as hell isn't simpler than "ifconfig" for most things I can think
of)

Linus

2014-12-31 22:20:04

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On Wed, Dec 31, 2014 at 01:57:59PM -0800, Linus Torvalds wrote:
> Side note: does anybody think that was really a good idea to begin
> with? I mean, Cisco iOS is just _soooo_ universally loved, right?

Well, at the time when it was "ip" came out, Cisco had a defacto
monopoly on routing equipment, and some of the folks who were working
on Linux networking had this insane dream of having Linux be better at
the routing game than Cisco (there was this minor issue of Cisco
having hardware assist for their fastpath :-). So I think I
*understand* the rationale behind the design choice, even though it's
probably not the decision I would have made at the time, and certainly
not with the benefit of 20/20 hindsight!

And I won't say that I *loved* IOS, but I certainly used it enough
when I was working in the MIT Network Operations group. :-)

> And yeah, I refuse to use "ip link" or other insane commands. Let's
> face it, "ifconfig" and "route" are perfectly fine commands, and a
> whole lot less confusing than "ip" with random crap after it. I'm
> really not seeing why that "ip" command was seen as an improvement.

The real problem is that they were trying to do way more complicated
things in terms of routing rules (including some stuff that could be
done by Cisco IOS). So if you want to try to do the insanely
complicated stuff, you have to use the "ip route" command.

Meh. Could it have been shoehorned into the legacy "route" command?
Perhaps, although it would have been a bit of mess, I suspect.

The question I find more interesting is how many people are actually
*using* all of the complexity that currently can only be accessed via
the "ip", "tc", and "ss" commands.

But in any case, given that "ip", "tc", "ss", etc. are using the IOS
syntax, most users will probably find it confusing and surprising that
"iw" is using something different. It's probably too hard to maintain
script compatibility to make such a UX change to iw at this point,
though. And besides, most users are probably using "ifconfig",
"route", and if they're not using network-manager or wicdw, they're
using "iwconfig" or "iwlist" --- so it's a moot point. :-)

- Ted

2014-12-31 22:30:25

[permalink] [raw]

Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"

On 12/31/14 22:44, Theodore Ts'o wrote:
> On Wed, Dec 31, 2014 at 09:32:13PM +0100, Arend van Spriel wrote:
>>
>> Agree. I can't even recall using "ip" ever. iw help system does provide
>> command specific help. The phy keyword is both a command and a selector key,
>> which I realize is confusing to the user, eg. 'iw help info' does provide
>> help for the 'info' subcommand.
>
> Yeah, the confusing part is that "ip" tends to use "verb object"
> scheme, which is consistent with the Cisco IOS command set it was
> trying to emulate. So for ip, you do something like
>
> ip link info eth0
>
> Where as for "iw" it's almost exactly backwards, i.e.:
>
> iw wlan0 info
>
> It's actually rather unfortunate that there is no consistency between
> many of these tools, for example:
>
> ethtool --show-features eth0
>
> If we were going to create a new interface, wouldn't be nice if we
> could have some kind of consistency? Sigh; oh well, water under the
> bridge at this point.

And on that water there are different ships with different captains ;-)

>> Thanks. If there are still drivers, upstream or out-of-tree, providing only
>> WEXT API this will not work unless iwconfig/iwlist can distinguish those
>> from cfg80211-based drivers (which is possible) and fallback to WEXT ioctl
>> syscalls. Just not sure if it is worth the effort. As you stated below, it
>> does not seem "evil" to retain WEXT if that is providing users what they
>> need.
>
> Is it really that much effort? Unless there is some license
> incompatibility nonsense (i.e., GPLv2 vs GPLv3), the code's already
> there in the wireless-tools source. It would just be a matter of
> trying the new ioctls first, and then falling back to the WEXT ones if
> needed, right?

I don't think it is much effort. I think the nl80211 netlink api is not
an ioctl, but yeah it seems trivial. But if WEXT needs to stay for
people using WEXT-only drivers, it may be fine to keep cfg80211 wext
compatibility in place.

Regards,
Arend

> Cheers,
>
> - Ted

2014-12-31 22:41:09