| Message ID | alpine.LNX.2.00.1412302351030.31609@pobox.suse.cz (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Johannes Berg |
| Headers | show |
> 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 <jkosina@suse.cz> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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<jkosina@suse.cz> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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<jkosina@suse.cz> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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<jkosina@suse.cz> >>> --- >>> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"); -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
Hi, On Thu, Jan 1, 2015 at 12:49 AM, Peter Hurley <peter@hurleysoftware.com> 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,
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.
Hi Borislav, On Thu, Jan 1, 2015 at 1:46 AM, Borislav Petkov <bp@alien8.de> 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,
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <jkosina@suse.cz> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 31, 2014 at 9:31 AM, Theodore Ts'o <tytso@mit.edu> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o <tytso@mit.edu> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/31/14 22:57, Linus Torvalds wrote: > On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o<tytso@mit.edu> 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? I think I sense a bit cynical (under)tone here ;-) > 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. So does "ip" provide the same functionality as "ifconfig" and "route" or does the package have more to offer. The "iw" tool provides much more subcommands to perform different wireless tasks that are not provided by "iwconfig" and friends. So functionally "iw" provides a superset. Just have to get equivalent output format to mimic "iwconfig" as Ted suggested. Well, that's something for next year as we are getting close to midnight over here. Regards, Arend > (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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 31 Dec 2014, Arend van Spriel wrote: > On 12/31/14 22:57, Linus Torvalds wrote: >> On Wed, Dec 31, 2014 at 1:44 PM, Theodore Ts'o<tytso@mit.edu> 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? > > I think I sense a bit cynical (under)tone here ;-) > >> 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. > > So does "ip" provide the same functionality as "ifconfig" and "route" or does > the package have more to offer. there are things that you can do with "ip" that you can't do with "ifconfig", but they tend to be rather esoteric things (hundreds of IP addresses on "eth0" without using eth0:1, eth0:2, etc as one example) The trouble is that doing simple things is harder with "ip" than "ifconfig" David Lang > The "iw" tool provides much more subcommands to perform different wireless > tasks that are not provided by "iwconfig" and friends. So functionally "iw" > provides a superset. Just have to get equivalent output format to mimic > "iwconfig" as Ted suggested. > > Well, that's something for next year as we are getting close to midnight over > here. > > Regards, > Arend > >> (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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arend van Spriel wrote: > On 12/31/14 16:14, Andreas Hartmann wrote: [...] >> 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). You seem to know sources I don't know off. Could you please tell me, where to find them? I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which RT_CFG80211_SUPPORT relies, is broken. DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP code completely. > This thread is about the configuration API and > not about driver performance. I know. I tried to show, why WEXT as a whole is still necessary even if there is a mac80211 based driver, because of the weakness of rt2800usb: Nip it in the bud. Kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 1, 2015 at 1:22 AM, David Lang <david@lang.hm> wrote: > there are things that you can do with "ip" that you can't do with > "ifconfig", but they tend to be rather esoteric things (hundreds of IP > addresses on "eth0" without using eth0:1, eth0:2, etc as one example) > > The trouble is that doing simple things is harder with "ip" than "ifconfig" Jan did a nice overview: http://inai.de/2008/02/19
On 01/01/15 11:56, Andreas Hartmann wrote: > Arend van Spriel wrote: >> On 12/31/14 16:14, Andreas Hartmann wrote: > [...] >>> 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). > > You seem to know sources I don't know off. Could you please tell me, > where to find them? > > I have DPO_RT5572_LinuxSTA_2.6.0.1_20120629 which doesn't compile with > HAS_CFG80211_SUPPORT=y because -DCONFIG_AP_SUPPORT, on which > RT_CFG80211_SUPPORT relies, is broken. > > DPO_RT5572_LinuxSTA_2.6.1.3_20121022 removed the necessary broken AP > code completely. Nice. >> This thread is about the configuration API and >> not about driver performance. > > I know. > > I tried to show, why WEXT as a whole is still necessary even if there is > a mac80211 based driver, because of the weakness of rt2800usb: > Nip it in the bud. Yes. WEXT needs to stay for a while. Not arguing that. Just saying this is really about cfg80211 providing "WEXT compatibility" so WEXT user-space apps can interact with cfg80211-based drivers and how to come up with a plan to phase out "WEXT compatibility", not WEXT. Regards, Arend > Kind regards, > Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? > > 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) Well at least in the past (not sure these days), ifconfig was reading rather inefficiently from /proc rather than using netlink, and it had annoying bugs like only showing the first 9 characters of the interface name, not handling IPv6 (I think that has been fixed by now), and many other awfulnesses. I just did a quick check to see how ifconfig does longer interface names and got this: tun0-12345678:2: error fetching interface information: Device not found for an interface I had renamed to tun0-123456789 ip had no issue with it. Renaming it to tun0-12345678 made ifconfig not die on it. I wonder if someone failed to understand that 15 character interface names meant that 15 characters before the NULL should be allowed. If did show all of the 14 characters though, so the old cut at 9 character limit is at least gone these days. ifconfig seems to just be broken for many cases of perfectly nice features in the kernel. So yes some parts of ip are pretty painful, while others are rather nice (I certainly like ip route, where the output actually matches the syntax of the input, unlike the route command). Would be nice if all features of the ip command were actually documented, but they clearly are not.
On Thu, Jan 1, 2015 at 11:44 AM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote: > > ifconfig seems to just be broken for many cases of perfectly nice features > in the kernel. So I'm not saying "ifconfig is wonderful". It's not. But I *am* saying that "changing user interfaces and then expecting people to change is f*cking stupid". The fact is, ifconfig is simple for the simple cases, but more importantly, a lot of people learnt how to use it. Saying "you should all change, because we made up a new syntax" is not good policy. The people who did "ip" could have fairly easily have done a wrapper around the same code that also left the old "ifconfig" syntax. Then, distros could have trivially just dropped the old "ifconfig" package, and entirely replaced it with the new "ip" package. As it is, we have two different models, and they'll basically stay around forever. For something like ifconfig, very few people care. But *all* the same arguments are true wrt "iw" and "iwconfig". The people who are trying to deprecate the WEXT interfaces should put the blame firmly where it belongs - on the people who thought that "we'll just ignore all old history". Because people who think that "we'll just redesign everything" are actually f*cking morons. Really. There's a real reason the kernel has the "no regression" policy. And that reason is that I'm not a moron. History matter. Legacy uses matter. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 01, 2015 at 12:14:15PM -0800, Linus Torvalds wrote: > So I'm not saying "ifconfig is wonderful". It's not. > > But I *am* saying that "changing user interfaces and then expecting > people to change is f*cking stupid". > > The fact is, ifconfig is simple for the simple cases, but more > importantly, a lot of people learnt how to use it. Saying "you should > all change, because we made up a new syntax" is not good policy. Perhaps it would be good to at least fix the buggy bits of ifconfig and perhaps make it work with netlink instead of parsing /proc. Maybe not add features, but at least fix the broken bits and make it use modern interfaces. The interface to the user can stay. And of course if it happens to encounter a really old kernel, it should still remember how to speak to it with the old interface. > The people who did "ip" could have fairly easily have done a wrapper > around the same code that also left the old "ifconfig" syntax. Then, > distros could have trivially just dropped the old "ifconfig" package, > and entirely replaced it with the new "ip" package. Hmm, that might be a better idea. > As it is, we have two different models, and they'll basically stay > around forever. > > For something like ifconfig, very few people care. But *all* the same > arguments are true wrt "iw" and "iwconfig". > > The people who are trying to deprecate the WEXT interfaces should put > the blame firmly where it belongs - on the people who thought that > "we'll just ignore all old history". > > Because people who think that "we'll just redesign everything" are > actually f*cking morons. Really. > > There's a real reason the kernel has the "no regression" policy. And > that reason is that I'm not a moron. > > History matter. Legacy uses matter. Sounds good to me.
On Wed 2014-12-31 08:49:00, Peter Hurley 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"); Kernel interfaces are not being removed, not now, not ever. No need to spam logs. (And to the person who suggested WARN(): No.) Pavel
On Thu, Jan 01, 2015 at 02:44:17PM -0500, Lennart Sorensen wrote: > not handling IPv6 (I think that has been fixed by now), and many > other awfulnesses. Some basic setting can be done. But it illustrates nicely what is wrong with the idea of extending ifconfig to support new features. IPv6 addresses are added and removed (which is how it really works) while with IPv4, ifconfig keeps pretending interface has exactly one address and to set more, a virtual interface must be created. In reality, both IPv4 and IPv6 addresses are handled in pretty much the same way. This "virtual interface" does not actually exist so that its parameters can't be set; and worse, if you try, ifconfig silently sets them for the actual interface (try e.g. "ifconfig eth0:0 mtu 1400"). You also can't use its name with other commands. Just google for users asking why iptables or tcpdump does not recognize their 'eth0:0'... and then people come and say that ip (unlike ifconfig) is confusing. But, yes, as the old ioctl interface can't be removed, lot of people will claim that ifconfig "just works" and that it must be preserved. And they will teach new generations of linux users to use it. So I'm afraid this exact discussion will be still repeated even after next 15 years. > Would be nice if all features of the ip command were actually documented, > but they clearly are not. As far as I can say, there may still be some missing parts but in recent versions, both manual pages and "ip ... help" cover the functions quite well (even if they are a bit too terse sometimes). On the other hand, "route --help" doesn't even tell me how to add a simple route. Michal Kubecek -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <jkosina@suse.cz> --- net/wireless/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)