The /sys/class/net/*/wireless/ direcory is, as far as I know, not
used by anyone. Additionally, the same data is available via wext
ioctls. Hence the sysfs files are pretty much useless. This patch
makes them optional and schedules them for removal.
Signed-off-by: Johannes Berg <[email protected]>
Cc: Jean Tourrilhes <[email protected]>
---
Documentation/feature-removal-schedule.txt | 8 ++++++++
net/core/net-sysfs.c | 4 ++--
net/wireless/Kconfig | 11 +++++++++++
3 files changed, 21 insertions(+), 2 deletions(-)
--- everything.orig/net/core/net-sysfs.c 2008-05-17 13:22:21.000000000 +0200
+++ everything/net/core/net-sysfs.c 2008-05-17 13:23:43.000000000 +0200
@@ -318,7 +318,7 @@ static struct attribute_group netstat_gr
.attrs = netstat_attrs,
};
-#ifdef CONFIG_WIRELESS_EXT
+#ifdef CONFIG_WIRELESS_EXT_SYSFS
/* helper function that does all the locking etc for wireless stats */
static ssize_t wireless_show(struct device *d, char *buf,
ssize_t (*format)(const struct iw_statistics *,
@@ -460,7 +460,7 @@ int netdev_register_kobject(struct net_d
if (net->get_stats)
*groups++ = &netstat_group;
-#ifdef CONFIG_WIRELESS_EXT
+#ifdef CONFIG_WIRELESS_EXT_SYSFS
if (net->wireless_handlers && net->wireless_handlers->get_wireless_stats)
*groups++ = &wireless_group;
#endif
--- everything.orig/net/wireless/Kconfig 2008-05-17 13:22:21.000000000 +0200
+++ everything/net/wireless/Kconfig 2008-05-17 14:09:01.000000000 +0200
@@ -29,3 +29,14 @@ config WIRELESS_EXT
Say N (if you can) unless you know you need wireless
extensions for external modules.
+
+config WIRELESS_EXT_SYSFS
+ bool "Wireless extensions sysfs files"
+ default y
+ depends on WIRELESS_EXT && SYSFS
+ help
+ This option enables the deprecated wireless statistics
+ files in /sys/class/net/*/wireless/. The same information
+ is available via the ioctls as well.
+
+ Say Y if you have programs using it (we don't know of any).
--- everything.orig/Documentation/feature-removal-schedule.txt 2008-05-17 13:22:20.000000000 +0200
+++ everything/Documentation/feature-removal-schedule.txt 2008-05-17 14:08:37.000000000 +0200
@@ -304,3 +304,11 @@ When: 2.6.26
Why: Implementation became generic; users should now include
linux/semaphore.h instead.
Who: Matthew Wilcox <[email protected]>
+
+---------------------------
+
+What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS
+ (in net/core/net-sysfs.c)
+When: June 2009
+Why: Not used by anyone, over 1K .text/.data size reduction.
+Who: Johannes Berg <[email protected]>
On Mon, 2008-05-19 at 17:39 +0200, Johannes Berg wrote:
> On Mon, 2008-05-19 at 11:24 -0400, Dan Williams wrote:
> > On Mon, 2008-05-19 at 14:16 +0200, Johannes Berg wrote:
> > > > Instead of testing for wireless/, best thing would probably be to call
> > > > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > > > wireless. Some drivers may have to load firmware to figure out
> > > > supported rates and encryption capabilities, but to be honest, NM does
> > > > this to detect wireless devices and I haven't run into any issues in 4
> > > > years using it. If there are issues with drivers, then we need to fix
> > > > the driver too.
> > >
> > > I was about to propose calling SIOCGIWNAME since that is what
> > > wireless-tools do and that linux/wireless.h indicates.
> >
> > Hmm; NAME is pretty useless. That's fine to do, I guess WEXT requires
> > that NAME return _something_ at least. NAME should never ever be used
> > for anything more, but since wireless-tools appears to do this that's
> > fine.
>
> Yes, I realise it is completely useless, but wext seems to require that
> it be implemented. RANGE would work as well but typically has much more
> complexity in the kernel.
Yup; NAME's better for this even though it's useless.
Dan
On Mon, 2008-05-19 at 11:24 -0400, Dan Williams wrote:
> On Mon, 2008-05-19 at 14:16 +0200, Johannes Berg wrote:
> > > Instead of testing for wireless/, best thing would probably be to call
> > > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > > wireless. Some drivers may have to load firmware to figure out
> > > supported rates and encryption capabilities, but to be honest, NM does
> > > this to detect wireless devices and I haven't run into any issues in 4
> > > years using it. If there are issues with drivers, then we need to fix
> > > the driver too.
> >
> > I was about to propose calling SIOCGIWNAME since that is what
> > wireless-tools do and that linux/wireless.h indicates.
>
> Hmm; NAME is pretty useless. That's fine to do, I guess WEXT requires
> that NAME return _something_ at least. NAME should never ever be used
> for anything more, but since wireless-tools appears to do this that's
> fine.
Yes, I realise it is completely useless, but wext seems to require that
it be implemented. RANGE would work as well but typically has much more
complexity in the kernel.
johannes
Hi Johannes,
> The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> used by anyone. Additionally, the same data is available via wext
> ioctls. Hence the sysfs files are pretty much useless. This patch
> makes them optional and schedules them for removal.
it is used by HAL to classify WiFi network cards as net.80211 instead
of net.80203 and so we do have an actual user. However HAL only tests
for the existence of the directory wireless/.
Please fix HAL first before submitting such a patch.
Regards
Marcel
On Mon, May 19, 2008 at 8:22 AM, Johannes Berg
<[email protected]> wrote:
> [removing linux-kernel and netdev from CC, I suppose they won't care too
> much about these details]
>
> On Mon, 2008-05-19 at 14:18 +0200, Johannes Berg wrote:
>> > Instead of testing for wireless/, best thing would probably be to call
>> > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
>> > wireless. Some drivers may have to load firmware to figure out
>> > supported rates and encryption capabilities, but to be honest, NM does
>> > this to detect wireless devices and I haven't run into any issues in 4
>> > years using it. If there are issues with drivers, then we need to fix
>> > the driver too.
>>
>> I was about to propose calling SIOCGIWNAME since that is what
>> wireless-tools do and that linux/wireless.h indicates.
>
> Here's a patch, comments?
>
> johannes
>
> ---
> hald/linux/device.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> --- hal.orig/hald/linux/device.c 2008-05-19 06:46:23.000000000 +0200
> +++ hal/hald/linux/device.c 2008-05-19 06:55:25.000000000 +0200
> @@ -45,6 +45,10 @@
> #include <linux/input.h>
> #endif
>
> +/* for wireless extensions */
> +#include <linux/if.h>
> +#include <linux/wireless.h>
> +
> #include <dbus/dbus.h>
> #include <dbus/dbus-glib.h>
>
> @@ -532,10 +536,14 @@ net_add (const gchar *sysfs_path, const
> const char *addr;
> const char *parent_subsys;
> char bridge_path[HAL_PATH_MAX];
> - char wireless_path[HAL_PATH_MAX];
> char phy80211_path[HAL_PATH_MAX];
> struct stat s;
> dbus_uint64_t mac_address = 0;
> + int ioctl_fd;
> + struct iwreq iwr;
> +
> + ioctl_fd = socket (PF_INET, SOCK_DGRAM, 0);
> + strncpy (iwr.ifr_ifrn.ifrn_name, IFNAMSIZ, ifname);
IFNAMSIZ should be the last argument.
Luis
[removing linux-kernel and netdev from CC, I suppose they won't care too
much about these details]
On Mon, 2008-05-19 at 14:18 +0200, Johannes Berg wrote:
> > Instead of testing for wireless/, best thing would probably be to call
> > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > wireless. Some drivers may have to load firmware to figure out
> > supported rates and encryption capabilities, but to be honest, NM does
> > this to detect wireless devices and I haven't run into any issues in 4
> > years using it. If there are issues with drivers, then we need to fix
> > the driver too.
>
> I was about to propose calling SIOCGIWNAME since that is what
> wireless-tools do and that linux/wireless.h indicates.
Here's a patch, comments?
johannes
---
hald/linux/device.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- hal.orig/hald/linux/device.c 2008-05-19 06:46:23.000000000 +0200
+++ hal/hald/linux/device.c 2008-05-19 06:55:25.000000000 +0200
@@ -45,6 +45,10 @@
#include <linux/input.h>
#endif
+/* for wireless extensions */
+#include <linux/if.h>
+#include <linux/wireless.h>
+
#include <dbus/dbus.h>
#include <dbus/dbus-glib.h>
@@ -532,10 +536,14 @@ net_add (const gchar *sysfs_path, const
const char *addr;
const char *parent_subsys;
char bridge_path[HAL_PATH_MAX];
- char wireless_path[HAL_PATH_MAX];
char phy80211_path[HAL_PATH_MAX];
struct stat s;
dbus_uint64_t mac_address = 0;
+ int ioctl_fd;
+ struct iwreq iwr;
+
+ ioctl_fd = socket (PF_INET, SOCK_DGRAM, 0);
+ strncpy (iwr.ifr_ifrn.ifrn_name, IFNAMSIZ, ifname);
addr = hal_device_property_get_string (d, "net.address");
if (addr != NULL) {
@@ -554,8 +562,6 @@ net_add (const gchar *sysfs_path, const
}
snprintf (bridge_path, HAL_PATH_MAX, "%s/bridge", sysfs_path);
- /* wireless extensions */
- snprintf (wireless_path, HAL_PATH_MAX, "%s/wireless", sysfs_path);
/* cfg80211 */
snprintf (phy80211_path, HAL_PATH_MAX, "%s/phy80211", sysfs_path);
parent_subsys = hal_device_property_get_string (parent_dev, "info.subsystem");
@@ -565,7 +571,7 @@ net_add (const gchar *sysfs_path, const
hal_device_property_set_string (d, "info.category", "net.bluetooth");
hal_device_add_capability (d, "net.bluetooth");
hal_device_property_set_uint64 (d, "net.bluetooth.mac_address", mac_address);
- } else if ((stat (wireless_path, &s) == 0 && (s.st_mode & S_IFDIR)) ||
+ } else if ((ioctl (ioctl_fd, SIOCGIWNAME, &iwr) == 0) ||
(stat (phy80211_path, &s) == 0 && (s.st_mode & S_IFDIR))) {
hal_device_property_set_string (d, "info.product", "WLAN Interface");
hal_device_property_set_string (d, "info.category", "net.80211");
@@ -582,6 +588,8 @@ net_add (const gchar *sysfs_path, const
hal_device_add_capability (d, "net.80203");
hal_device_property_set_uint64 (d, "net.80203.mac_address", mac_address);
}
+
+ close (ioctl_fd);
} else if (media_type == ARPHRD_IRDA) {
hal_device_property_set_string (d, "info.product", "Networking Interface");
hal_device_property_set_string (d, "info.category", "net.irda");
On Sat, 2008-05-17 at 15:45 +0200, Marcel Holtmann wrote:
> Hi Johannes,
>
> > The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> > used by anyone. Additionally, the same data is available via wext
> > ioctls. Hence the sysfs files are pretty much useless. This patch
> > makes them optional and schedules them for removal.
>
> it is used by HAL to classify WiFi network cards as net.80211 instead
> of net.80203 and so we do have an actual user. However HAL only tests
> for the existence of the directory wireless/.
>
> Please fix HAL first before submitting such a patch.
I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at
https://bugs.freedesktop.org/show_bug.cgi?id=16037. Any further
objections to this patch?
johannes
On Mon, May 19, 2008 at 02:16:08PM +0200, Johannes Berg wrote:
>
> > Instead of testing for wireless/, best thing would probably be to call
> > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > wireless. Some drivers may have to load firmware to figure out
> > supported rates and encryption capabilities, but to be honest, NM does
> > this to detect wireless devices and I haven't run into any issues in 4
> > years using it. If there are issues with drivers, then we need to fix
> > the driver too.
>
> I was about to propose calling SIOCGIWNAME since that is what
> wireless-tools do and that linux/wireless.h indicates.
>
> johannes
Yes, using SIOCGIWNAME is the right way to do it, it's the
only ioctl that is guarantee to always be present and require minimal
processing from the driver (it should be a static string). If you look
at iwconfig, this is how it does it.
(Sorry for the delay replying, I was chasing kids and
electrical faults this week end).
Have fun...
Jean
Hi Johannes,
>>> The /sys/class/net/*/wireless/ direcory is, as far as I know, not
>>> used by anyone. Additionally, the same data is available via wext
>>> ioctls. Hence the sysfs files are pretty much useless. This patch
>>> makes them optional and schedules them for removal.
>>
>> it is used by HAL to classify WiFi network cards as net.80211 instead
>> of net.80203 and so we do have an actual user. However HAL only tests
>> for the existence of the directory wireless/.
>
> Oh, ok, I didn't know that, thanks.
>
>> Please fix HAL first before submitting such a patch.
>
> Sure, I'll take a look at that.
saw your patch. Looks good to me. However what do we do with the non-
mac80211 drivers that are using WEXT directly. These should be
detected as net.80211, too.
Regards
Marcel
> > I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at
> > https://bugs.freedesktop.org/show_bug.cgi?id=16037. Any further
> > objections to this patch?
>
> I think this is going to fall under the "userland ABI" category.
> We can make it a configurable option, but I don't think we are free
> to remove it completely since there is at least existing versions of
> HAL that use it.
Well, yes, I gave it a year in the feature removal schedule since I
thought nobody was actually using it. But if you look at how hal/sysfs
are always dependent on new versions of each other *anyway*, I think we
can get away with removing this in maybe two years time, and
distributors can unset the option if they know their hal is new enough?
johannes
On Mon, 2008-05-19 at 14:16 +0200, Johannes Berg wrote:
> > Instead of testing for wireless/, best thing would probably be to call
> > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > wireless. Some drivers may have to load firmware to figure out
> > supported rates and encryption capabilities, but to be honest, NM does
> > this to detect wireless devices and I haven't run into any issues in 4
> > years using it. If there are issues with drivers, then we need to fix
> > the driver too.
>
> I was about to propose calling SIOCGIWNAME since that is what
> wireless-tools do and that linux/wireless.h indicates.
Hmm; NAME is pretty useless. That's fine to do, I guess WEXT requires
that NAME return _something_ at least. NAME should never ever be used
for anything more, but since wireless-tools appears to do this that's
fine.
Dan
On Tue, May 20, 2008 at 07:15:31PM +0200, Johannes Berg wrote:
> On Sat, 2008-05-17 at 15:45 +0200, Marcel Holtmann wrote:
> > Hi Johannes,
> >
> > > The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> > > used by anyone. Additionally, the same data is available via wext
> > > ioctls. Hence the sysfs files are pretty much useless. This patch
> > > makes them optional and schedules them for removal.
> >
> > it is used by HAL to classify WiFi network cards as net.80211 instead
> > of net.80203 and so we do have an actual user. However HAL only tests
> > for the existence of the directory wireless/.
> >
> > Please fix HAL first before submitting such a patch.
>
> I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at
> https://bugs.freedesktop.org/show_bug.cgi?id=16037. Any further
> objections to this patch?
I think this is going to fall under the "userland ABI" category.
We can make it a configurable option, but I don't think we are free
to remove it completely since there is at least existing versions of
HAL that use it.
John
--
John W. Linville
[email protected]
On Sat, 2008-05-17 at 15:54 +0200, Johannes Berg wrote:
> On Sat, 2008-05-17 at 15:45 +0200, Marcel Holtmann wrote:
> > Hi Johannes,
> >
> > > The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> > > used by anyone. Additionally, the same data is available via wext
> > > ioctls. Hence the sysfs files are pretty much useless. This patch
> > > makes them optional and schedules them for removal.
> >
> > it is used by HAL to classify WiFi network cards as net.80211 instead
> > of net.80203 and so we do have an actual user. However HAL only tests
> > for the existence of the directory wireless/.
>
> Oh, ok, I didn't know that, thanks.
>
> > Please fix HAL first before submitting such a patch.
>
> Sure, I'll take a look at that.
Instead of testing for wireless/, best thing would probably be to call
SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
wireless. Some drivers may have to load firmware to figure out
supported rates and encryption capabilities, but to be honest, NM does
this to detect wireless devices and I haven't run into any issues in 4
years using it. If there are issues with drivers, then we need to fix
the driver too.
dan
> Instead of testing for wireless/, best thing would probably be to call
> SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> wireless. Some drivers may have to load firmware to figure out
> supported rates and encryption capabilities, but to be honest, NM does
> this to detect wireless devices and I haven't run into any issues in 4
> years using it. If there are issues with drivers, then we need to fix
> the driver too.
I was about to propose calling SIOCGIWNAME since that is what
wireless-tools do and that linux/wireless.h indicates.
johannes
Hi Johannes,
>>> The /sys/class/net/*/wireless/ direcory is, as far as I know, not
>>> used by anyone. Additionally, the same data is available via wext
>>> ioctls. Hence the sysfs files are pretty much useless. This patch
>>> makes them optional and schedules them for removal.
>>
>> it is used by HAL to classify WiFi network cards as net.80211 instead
>> of net.80203 and so we do have an actual user. However HAL only tests
>> for the existence of the directory wireless/.
>>
>> Please fix HAL first before submitting such a patch.
>
> I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at
> https://bugs.freedesktop.org/show_bug.cgi?id=16037. Any further
> objections to this patch?
patch looks good to me.
Regards
Marcel
On Mon, May 19, 2008 at 11:24:46AM -0400, Dan Williams wrote:
> On Mon, 2008-05-19 at 14:16 +0200, Johannes Berg wrote:
> > > Instead of testing for wireless/, best thing would probably be to call
> > > SIOCGIWRANGE on the device and if it returns EOPNOTSUP then it's not
> > > wireless. Some drivers may have to load firmware to figure out
> > > supported rates and encryption capabilities, but to be honest, NM does
> > > this to detect wireless devices and I haven't run into any issues in 4
> > > years using it. If there are issues with drivers, then we need to fix
> > > the driver too.
> >
> > I was about to propose calling SIOCGIWNAME since that is what
> > wireless-tools do and that linux/wireless.h indicates.
>
> Hmm; NAME is pretty useless. That's fine to do, I guess WEXT requires
> that NAME return _something_ at least. NAME should never ever be used
> for anything more, but since wireless-tools appears to do this that's
> fine.
>
> Dan
It's not useless, it's supposed to tell you about the protocol
capability of the device, like "IEEE 802.11b" or "IEEE 802.11abg".
Have fun...
Jean
On Sat, 2008-05-17 at 15:45 +0200, Marcel Holtmann wrote:
> Hi Johannes,
>
> > The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> > used by anyone. Additionally, the same data is available via wext
> > ioctls. Hence the sysfs files are pretty much useless. This patch
> > makes them optional and schedules them for removal.
>
> it is used by HAL to classify WiFi network cards as net.80211 instead
> of net.80203 and so we do have an actual user. However HAL only tests
> for the existence of the directory wireless/.
Oh, ok, I didn't know that, thanks.
> Please fix HAL first before submitting such a patch.
Sure, I'll take a look at that.
johannes
On Sat, 2008-05-17 at 16:36 +0200, Marcel Holtmann wrote:
> Hi Johannes,
>
> >>> The /sys/class/net/*/wireless/ direcory is, as far as I know, not
> >>> used by anyone. Additionally, the same data is available via wext
> >>> ioctls. Hence the sysfs files are pretty much useless. This patch
> >>> makes them optional and schedules them for removal.
> >>
> >> it is used by HAL to classify WiFi network cards as net.80211 instead
> >> of net.80203 and so we do have an actual user. However HAL only tests
> >> for the existence of the directory wireless/.
> >
> > Oh, ok, I didn't know that, thanks.
> >
> >> Please fix HAL first before submitting such a patch.
> >
> > Sure, I'll take a look at that.
>
> saw your patch. Looks good to me. However what do we do with the non-
> mac80211 drivers that are using WEXT directly. These should be
> detected as net.80211, too.
Yes, this was just a bigfix while I was looking at the code, I'll look
into that too :)
johannes
Umm, wrong subject, should be
"make wext sysfs bits [...]"
johannes