cfg80211 merge

From: Johannes Berg <[email protected]>

This patch moves net/core/wireless.c to net/wireless/wext.c. I refrained from further cleanups though I was tempted. Hence this is a pure file move plus various build system adjustments.

Is this the right name? Shouldn't it be wext-ioctl.c given that we'll hopefull soon grow a wext implementation with a proper method table interface for drivers.

include/linux/nl80211.h new file +2 -0

+	NL80211_ATTR_SSID,
+

+ * @list_interfaces: for each interfaces belonging to the wiphy identified
+ * by the priv pointer, call the one() function with the
+ * given data and the ifindex. This callback is required.
+ *

I think drivers that currently support frame injection do it by allowing TX on a monitor interface w/ AVS or radiotap header. I would rather have this than requiring the use of NL80211 to inject frames since userspace won't have to do as much to continue supporting frame injection. It also makes more sense to me. Status notification can be done by a 802.11 ACK frame. Radiotap might need to be extended to support toggling the ACK frame reporting for TX and whatever else userspace wants to set.

Quoted 7 lines · Michael Wu

I think drivers that currently support frame injection do it by allowing TX on a monitor interface w/ AVS or radiotap header. I would rather have this than requiring the use of NL80211 to inject frames since userspace won't have to do as much to continue supporting frame injection. It also makes more sense to me. Status notification can be done by a 802.11 ACK frame. Radiotap might need to be extended to support toggling the ACK frame reporting for TX and whatever else userspace wants to set.

Please, don't do that. You need to get a success/failure report from the driver/stack. Doing that by dumping fake frames through the network interfaces isn't something I could consider as a right behaviour. Also, you need to match the sent frame and the report from the driver. This gets really tricky when you use network interfaces.

I think drivers that currently support frame injection do it by allowing TX on a monitor interface w/ AVS or radiotap header. I would rather have this than requiring the use of NL80211 to inject frames since userspace won't have to do as much to continue supporting frame injection. It also makes more sense to me. Status notification can be done by a 802.11 ACK frame. Radiotap might need to be extended to support toggling the ACK frame reporting for TX and whatever else userspace wants to set.

include/linux/nl80211.h line 56

Quoted 3 lines

include/linux/nl80211.h new file +3 -0

+	/* configuration sent from kernel */
+	NL80211_CMD_NEW_CONFIG,
+

Why NEW?

[snip]

include/linux/nl80211.h line 87

Quoted 3 lines

include/linux/nl80211.h new file +3 -0

+	/* currently set roaming BSSID */
+	NL80211_CMD_FIXED_BSSID,
+

Wasn't immediately obvious to me that this is from GET_FIXED_BSSID.

include/linux/nl80211.h line 94

Quoted 7 lines

include/linux/nl80211.h new file +7 -0

+	/* get current association information, if not associated then
+	 * the BSSID attribute is not present in response */
+	NL80211_CMD_GET_ASSOCIATION,
+
+	/* association notification and response to GET_BSSID */
+	NL80211_CMD_ASSOCIATION_CHANGED,
+

I don't see a GET_BSSID. Did you mean GET_ASSOCIATION?

[snip]

include/linux/nl80211.h line 164

Quoted 4 lines

include/linux/nl80211.h new file +4 -0

+	/* attributes used for configuration */
+	/* network ID (pre 802.11 HW) */
+	NL80211_ATTR_NETWORK_ID,
+

We really want to support (and port) pre 802.11 drivers?

[snip]

include/linux/nl80211.h line 185

Quoted 1 line

include/linux/nl80211.h new file +1 -0

+	/* SSID of ESS to associate to */

BSS?

Quoted 4 lines

+ * @list_interfaces: for each interfaces belonging to the wiphy identified
+ * by the priv pointer, call the one() function with the
+ * given data and the ifindex. This callback is required.
+ *

Do we really have to have this?

I disagree. Generic netlink is trivially extensible while radiotap isn't, and I really don't want a radiotap parser in the kernel. Secondly, a lot of notification items will only be given via netlink anyway, like failed decryption or whatever, and we don't want to keep all this in fake management frames.

Okay then, let's not use fake frames then.

Let's make monitor interfaces
resemble monitoring ethernet a little more by reporting both RXed frames and TXed frames. *BSD does this too and it makes running ethereal on monitor interfaces much more useful.

TX frame reporting can be done simply in the ieee80211_tx_status call, allowing the TX status to be reported on real frames.

Doing this is actually somewhat orthogonal to packet injection via netlink or monitor interface, but if we are reporting TXed frames with a radiotap header, we might as well allow frame injection with a radiotap frame for consistency.

Quoted 4 lines

Let's make monitor interfaces
resemble monitoring ethernet a little more by reporting both RXed frames and TXed frames. *BSD does this too and it makes running ethereal on monitor interfaces much more useful.

We do this right now afaik.

Quoted 3 lines

TX frame reporting can be done simply in the ieee80211_tx_status call, allowing the TX status to be reported on real frames.

I don't quite understand this comment. TX status reporting should go via nl80211.

Quoted 4 lines

Doing this is actually somewhat orthogonal to packet injection via netlink or monitor interface, but if we are reporting TXed frames with a radiotap header, we might as well allow frame injection with a radiotap frame for consistency.

Well, it hasn't got much merit because for anything useful you'll need to get state information on nl80211.

Where? I don't remember getting TX frames when running ethereal on a monitor interface.

If we report TXed frames at the point when the driver calls ieee80211_tx_status, we know whether or not an ack was received. This information can be added to the TX frame that is reported to the monitor interface.

I'm not sure what you mean. The program can get the configuration info it needs from nl80211/cfg80211/WE and send/inject frames through the monitor interface.

Oh but do we really want to report them that late? I wouldn't think so. That would give us out-of-order issues wrt. the air...

Well, I guess I'm saying that wpa_supplicant shouldn't need the monitor iface at all since it wants just management frames and we should give those to it via netlink to avoid having to add more radiotap foo.

No. It's the other way around, when they're reported immediately, they will be out of order. ieee80211_tx_status is called from the interrupt handler as the result of the frame being actually sent. Before that, a frame can sit for an arbitrary long time in the hw queue or not sent at all. Reporting only frames confirmed by ieee80211_tx_status as successfully sent at the time the function is called reflects better what is on the air (it's still not perfect as things like retransmissions are not caught).

No. It's the other way around, when they're reported immediately, they will be out of order. ieee80211_tx_status is called from the interrupt handler as the result of the frame being actually sent. Before that, a frame can sit for an arbitrary long time in the hw queue or not sent at all. Reporting only frames confirmed by ieee80211_tx_status as successfully sent at the time the function is called reflects better what is on the air (it's still not perfect as things like retransmissions are not caught).

Quoted 3 lines

I'm not sure what you mean. The program can get the configuration info it needs from nl80211/cfg80211/WE and send/inject frames through the monitor interface.

Well, I guess I'm saying that wpa_supplicant shouldn't need the monitor iface at all since it wants just management frames and we should give those to it via netlink to avoid having to add more radiotap foo.

Anyway, netlink does not seem appropriate for
sending or receiving frames.

Quoted 2 lines · Michael Wu

Anyway, netlink does not seem appropriate for
sending or receiving frames.

Care to explain why you think so?

1. Userspace usually expects to send things on network interfaces. The kernel usually receives frames from userspace on network interfaces. I don't see the point of making an exception for 802.11 frames. (or rather, the potential for simpler frame injection code is not enough to justify inventing a new interface for doing it)

2. nl80211/cfg80211 is for configuring interfaces. Everything there is related to configuration of wireless interfaces except for the frame injection hook. It doesn't look right.

Quoted 4 lines

Let's make monitor interfaces
resemble monitoring ethernet a little more by reporting both RXed frames and TXed frames. *BSD does this too and it makes running ethereal on monitor interfaces much more useful.

We do this right now afaik.

Quoted 3 lines

TX frame reporting can be done simply in the ieee80211_tx_status call, allowing the TX status to be reported on real frames.

I don't quite understand this comment. TX status reporting should go via nl80211.

In London we agreed that it would be good to go ahead and merge cfg80211.

Let me know if I've left anything out, screwed anything up, or if you no longer think a cfg80211 merge is appropriate at this time.

I'm all for getting this into the mainline kernel as soon as possible, but I do not think that this should happen before there are user space programs that demonstrate that cfg80211 can be used without problems and that the kernel side implementation is complete enough to allow some meaningful operations to be completed with cfg80211 (likely with WEXT disabled, i.e., cfg80211 being feature complete for, say, WPA authentication).

Quoted 7 lines · Jouni Malinen

I'm all for getting this into the mainline kernel as soon as possible, but I do not think that this should happen before there are user space programs that demonstrate that cfg80211 can be used without problems and that the kernel side implementation is complete enough to allow some meaningful operations to be completed with cfg80211 (likely with WEXT disabled, i.e., cfg80211 being feature complete for, say, WPA authentication).

I fully agree with Jouni.

OK, where were you guys in London? I don't recall any disagreement there?

The WEXT compat code should be enough to drive the cfg80211 code. And we would mark it CONFIG_EXPERIMENTAL (which I left out of the patch) for now. I suppose we could leave-out the nl80211 part to avoid userland lock-in for now?

This also has the advantage of including the ieee80211_ptr in the net_device structure, hopefully easing the task of packaging the rest of the stack for external builds.

I suppose we could wait for at least one driver to be cfg80211-capable. Would that satisfy everyone?

Quoted 2 lines · John W. Linville

OK, where were you guys in London? I don't recall any disagreement there?

Hm, I remember we agreed that merging of d80211 and cfg80211/nl80211 are two separate things. And a discussion about cfg80211/nl80211 not being quite ready yet (if I remember correctly, Jouni participated in that discussion). But well, it was just informal and maybe I missed something else.

Quoted 9 lines · Jiri Benc

Quoted 2 lines · John W. Linville

OK, where were you guys in London? I don't recall any disagreement there?

Hm, I remember we agreed that merging of d80211 and cfg80211/nl80211 are two separate things. And a discussion about cfg80211/nl80211 not being quite ready yet (if I remember correctly, Jouni participated in that discussion). But well, it was just informal and maybe I missed something else.

Yes, cfg80211 should go in first so we can use it to avoid all the boilerplate code in existing and new drivers. Once we have netlink-capable userspace nl80211 can be added ontop of that. This also allows for possibly needed adjustments of the nl interface when writing the tools actually using it.

Agreed. I (and/or Johannes?) will rework the patches to remove the nl bits.

Quoted 2 lines · John W. Linville

Agreed. I (and/or Johannes?) will rework the patches to remove the nl bits.

Starting tomorrow I can devote some time again.

Maybe we should resurrect those wiphy patches I had first?

johannes

_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless

As far as I tested cfg80211 compatibility mode is incomplete. You cannot run hostapd over it
If I recall correctly PRISM2_IOCTL_PRISM2_PARAM and friends are not passed to d80211

Quoted 4 lines · Tomas Winkler

As far as I tested cfg80211 compatibility mode is incomplete. You cannot run hostapd over it
If I recall correctly PRISM2_IOCTL_PRISM2_PARAM and friends are not passed to d80211

It's a priv ioctl, it's not supposed to be passed on.

johannes (who is getting positively pissed off about such requests)

Can you elaborate shortly. I'm not from time 0 on this list.

Quoted 1 line · Tomas Winkler

Can you elaborate shortly. I'm not from time 0 on this list.

Well. cfg80211 will replace the common wext ioctls. All the private wext ioctls will not be handled there.

The rationale is that
(1) it doesn't delete priv ioctls, they'll still work for the migration period
(2) you can't rely on private ioctls having a certain meaning for each driver, ie. other drivers are free the reassign numbers of sub-ioctls
(3) any behaviour that is generally useful should be standardised.

johannes

I don't know who is missing something here, but what I'm saying that
(1) is not correct. priv ioctls don't work with compatibility set on.

Can you elaborate shortly. I'm not from time 0 on this list. Thanks.

include/linux/netdevice.h +1 -0

index c1e9962..6a9b4c8 100644
@@ -348,12 +348,17 @@ struct net_device
 
 	struct net_device_stats* (*get_stats)(struct net_device *dev);
 
+#ifdef CONFIG_WIRELESS_EXT
 	/* List of functions to handle Wireless Extensions (instead of ioctl).

include/linux/netdevice.h +22 -0

@@ -2798,6 +2799,39 @@ int dev_ioctl(unsigned int cmd, void __user *arg)
 					ret = -EFAULT;
 				return ret;
 			}
+#ifdef CONFIG_CFG80211_WEXT_COMPAT
+			/* Take care of cfg80211 WE compatibility */
+			if (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) {
+				/* If command is `set a parameter', or
+				 * `get the encoding parameters', check if
+				 * the user has the right to do it */
+				if (IW_IS_SET(cmd) || cmd == SIOCGIWENCODE
+				    || cmd == SIOCGIWENCODEEXT) {
+					if (!capable(CAP_NET_ADMIN))
+						return -EPERM;
+				}
+				dev_load(ifr.ifr_name);
+				rtnl_lock();
+				/* Follow me in net/wireless/wext-compat.c */
+				ret = cfg80211_wext_ioctl(&ifr, cmd);
+				rtnl_unlock();
+				if (ret == 0 && IW_IS_GET(cmd) &&
+				    copy_to_user(arg, &ifr,
+						 sizeof(struct ifreq)))
+					ret = -EFAULT;
+				/* haha, I cheat here by allowing a driver or
+				 * stack to have both WE or CFG80211-WE for

net/wireless/Makefile +0 -0

index 663a7d8..62e67b7 100644
@@ -4,3 +4,13 @@ cfg80211-objs := \
 	core.o
 
 obj-$(CONFIG_WIRELESS_EXT) += wext-old.o

Do we really have to add this directly to struct net_device and bloat it for all users? I'd put this behind ieee80211_ptr instead unless there's a good reason against that.

Quoted 7 lines

net/Kconfig +7 -0

+config CFG80211_WEXTNL_COMPAT
+	bool "cfg80211 WE-netlink compatibility"
+	depends CFG80211 && CFG80211_WEXT_COMPAT
+	---help---
+	This option allows using devices whose drivers have been
+	converted to use the new cfg80211 with wireless extensions
+	over rtnetlink, providing WE-20 compatibility. Note that

net/Kconfig config FIB_RULES · line 258

Quoted 6 lines

net/Kconfig +6 -0

+	cfg80211's "native" interface is nl80211 using generic netlink.
+	The wireless extensions are being deprecated and the netlink
+	based API for WE was never configured by default, nor do any
+	userspace tools use this feature.
+
+	This option exists only to make Jean happy. Say N.

Should we really put this code in? It seems like unessecary bloat to me.

Quoted 31 lines

net/core/dev.c +27 -0

@@ -2798,6 +2799,39 @@ int dev_ioctl(unsigned int cmd, void __user *arg)
 					ret = -EFAULT;
 				return ret;
 			}
+#ifdef CONFIG_CFG80211_WEXT_COMPAT
+			/* Take care of cfg80211 WE compatibility */
+			if (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) {
+				/* If command is `set a parameter', or
+				 * `get the encoding parameters', check if
+				 * the user has the right to do it */
+				if (IW_IS_SET(cmd) || cmd == SIOCGIWENCODE
+				    || cmd == SIOCGIWENCODEEXT) {
+					if (!capable(CAP_NET_ADMIN))
+						return -EPERM;
+				}
+				dev_load(ifr.ifr_name);
+				rtnl_lock();
+				/* Follow me in net/wireless/wext-compat.c */
+				ret = cfg80211_wext_ioctl(&ifr, cmd);
+				rtnl_unlock();
+				if (ret == 0 && IW_IS_GET(cmd) &&
+				    copy_to_user(arg, &ifr,
+						 sizeof(struct ifreq)))
+					ret = -EFAULT;
+				/* haha, I cheat here by allowing a driver or
+				 * stack to have both WE or CFG80211-WE for
+				 * a little while during conversion... hope that
+				 * ENOSYS is only used to indicate not implemented
+				 *
+				 * if wireless extensions are not configured
+				 * then this is the last thing here so that

net/core/dev.c int dev_ioctl(unsigned int cmd, void __user *arg) · line 2833

Quoted 5 lines

net/core/dev.c +5 -0

+				 * if we fall through we return -EINVAL
+				 */
+				if (ret != -ENOSYS)
+					return ret;
+			}

Can we split this into a nice little helper function in wext-compat.c or a dummy macro if it's not configured?

net/core/rtnetlink.c line 61

Quoted 9 lines

net/core/rtnetlink.c +3 -0

@@ -56,6 +56,9 @@
 #include <linux/wireless.h>
 #include <net/iw_handler.h>
 #endif	/* CONFIG_NET_WIRELESS_RTNETLINK */
+#ifdef CONFIG_CFG80211_WEXTNL_COMPAT
+#include <net/cfg80211.h>
+#endif

There's not point in including headers conditionally.

This looks odd. Kbuild filters out duplicate objects, so something like the snipplet below should work aswell:

obj-$(CONFIG_WIRELESS_EXT) += wext-common.o wext-old.o
obj-$(CONFIG_CFG80211_WEXT_COMPAT) += wext-common.o wext-compat.o

net/core/rtnetlink.c line 64

Quoted 3 lines

net/core/rtnetlink.c +3 -0

+#ifdef CONFIG_CFG80211_WEXT_COMPAT
+/* wext compatibility must be compiled in...
+ * this extern is in wext-compat.c */

Is there really a point in making cfg80211 a loadable module? This whle operation vector stuff looks like a lot of unnessecary complexity to me.

net/wireless/wext-common.c line 1

Quoted 6 lines

new file mode 100644
index 0000000..c1de1d7

net/wireless/wext-common.c new file +1 -0

@@ -0,0 +1,610 @@
+/* common wext support routines, proc interface and events */

This is mostly Jean's old code, right? Probably wants at least some attribution.

Btw, if we submit cfg80211 for inclusion there should be at least one patch in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

Quoted 4 lines · Christoph Hellwig

Btw, if we submit cfg80211 for inclusion there should be at least one patch in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Quoted 8 lines · Johannes Berg

Quoted 1 line · Christoph Hellwig

Btw, if we submit cfg80211 for inclusion there should be at least one

patch

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211. With this we wouldn't have to wait for the next userspace nl80211 application to start testing cfg80211 directly (without wireless extensions compat). A configfs frontend can also allow more rapid development of userspace interfaces to configure wireless devices through cfg80211. Comments?

Quoted 10 lines · Luis R. Rodriguez

Quoted 8 lines · Johannes Berg

Quoted 1 line · Christoph Hellwig

Btw, if we submit cfg80211 for inclusion there should be at least one

patch

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Quoted 8 lines

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211. With this we wouldn't have to wait for the next userspace nl80211 application to start testing cfg80211 directly (without wireless extensions compat). A configfs frontend can also allow more rapid development of userspace interfaces to configure wireless devices through cfg80211. Comments?

Luis,

You have mentioned this before, and FWIW I think it is a decent idea. Let's see some code! :-)

Still, I don't think it changes the issue that we need a driver (or stack) plugged-in to the bottom end. I have this on my personal list of "soon TODO", although I haven't picked a driver yet.

If anyone is working on a cfg80211 driver conversion, please speak-up so we can avoid duplicating work.

Quoted 22 lines · John W. Linville

Quoted 10 lines · Luis R. Rodriguez

Quoted 8 lines · Johannes Berg

Quoted 1 line · Christoph Hellwig

Btw, if we submit cfg80211 for inclusion there should be at least one

patch

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Quoted 8 lines

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211. With this we wouldn't have to wait for the next userspace nl80211 application to start testing cfg80211 directly (without wireless extensions compat). A configfs frontend can also allow more rapid development of userspace interfaces to configure wireless devices through cfg80211. Comments?

Luis,

Quoted 2 lines

You have mentioned this before, and FWIW I think it is a decent idea. Let's see some code! :-)

I know, I know, talk is cheap, trust me, I abide by this motto every day. I actually wanted to just code this up and send this as part of my comment but do have other responsibilities I have to attend to first. I figured I'd throw it out though in case someone who does have time is willing to pick it up as I think it would be great for us.

Quoted 5 lines

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211.

Quoted 4 lines · Luis R. Rodriguez

Quoted 4 lines

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

Quoted 5 lines

Quoted 1 line

I guess I could make softmac use it.

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211.

Huh? We already have a wext fronted to nicely test cfg80211, what we need are backends.

In addition to that I think we should agree on
one primary userspace configuration method for the future instead of adding lots of them just because it's so easy.

If the public opinion
has changed 180 degrees and configs is preferred over nl80211 that's fine by me as long as the implementation is sane..

Quoted 9 lines · Luis R. Rodriguez

Quoted 5 lines

Quoted 3 lines

in the series actually converts a driver to use it. Both to make this code not dead and give people and example on how to use the cfg80211 infrastructure.

I guess I could make softmac use it.

Another idea here is we can provide a configfs frontend to cfg80211 therefore any device which implements cfg80211 will automagically have a userspace frontend (/configfs/wireless/foo) ready to test cfg80211.

Huh? We already have a wext fronted to nicely test cfg80211, what we need are backends. In addition to that I think we should agree on one primary userspace configuration method for the future instead of adding lots of them just because it's so easy. If the public opinion has changed 180 degrees and configs is preferred over nl80211 that's fine by me as long as the implementation is sane..

From: Johannes Berg <[email protected]>

This patch adds cfg80211, a new configuration system for wireless hardware.

It currently features a bunch of configuration requests, support for adding and removing virtual interfaces, the ability to inject packets and more.

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by John W. Linville <[email protected]>

---
 include/linux/netdevice.h  |    1 +
 include/net/cfg80211.h     |  186 ++++++++++++++++++++++++++++++++++++++++++++
 net/Kconfig                |    3 +
 net/Makefile               |    1 +
 net/wireless/Makefile      |    4 +
 net/wireless/core.c        |  158 +++++++++++++++++++++++++++++++++++++
 net/wireless/core.h        |   57 ++++++++++++++
 net/wireless/wext-compat.c |   25 ++++++
 8 files changed, 435 insertions(+), 0 deletions(-)

include/linux/netdevice.h +1 -0

index fea0d9d..c1e9962 100644
@@ -398,6 +398,7 @@ struct net_device
 	void                    *ip6_ptr;       /* IPv6 specific data */
 	void			*ec_ptr;	/* Econet specific data	*/
 	void			*ax25_ptr;	/* AX.25 specific data */
+	void			*ieee80211_ptr;	/* IEEE 802.11 specific data */
 
 /*
  * Cache line mostly used on receive path (including eth_type_trans())

Quoted 2 lines

+/*
+ * This is the new wireless configuration interface.

I don't think new makes a lot of sense here, it's hopefully the standad one soon.

Quoted 7 lines

+ *
+ * Copyright 2006 Johannes Berg <[email protected]>
+ */

net/wireless/core.c new file +4 -0

+
+#include "core.h"
+#include <linux/if.h>
+#include <linux/module.h>

net/wireless/core.c line 14

Quoted 5 lines

net/wireless/core.c new file +5 -0

+#include <linux/err.h>
+#include <net/genetlink.h>
+#include <net/cfg80211.h>
+#include <linux/mutex.h>
+#include <linux/list.h>

This include order seems odd. We normally include local headers last and net/ after linux/

net/wireless/core.c line 17

Quoted 2 lines

net/wireless/core.c new file +2 -0

+MODULE_AUTHOR("Johannes Berg");
+MODULE_LICENSE("GPL");

Can you please add a MODULE_DESCRIPTION aswell?

net/wireless/core.c line 23

Quoted 6 lines

net/wireless/core.c new file +6 -0

+
+/* RCU might be appropriate here since we usually
+ * only read the list, and that can happen quite
+ * often because we need to do it for each command */
+LIST_HEAD(cfg80211_drv_list);
+DEFINE_MUTEX(cfg80211_drv_mutex);

Any reason these are non-static? They aren't actually used outside of this file, and in general having non-static lists isn't very nice, we prefer having proper accessor functions.

net/wireless/wext-compat.c line 2

Quoted 5 lines

net/wireless/wext-compat.c new file +2 -0

@@ -0,0 +1,25 @@
+/* NOT YET */
+

huh? this file isn't added to the build process and only contains a (non-standard formatted) comment. No point in adding it in this patch.

Quoted 4 lines

net/wireless/core.c line 17

Quoted 2 lines

net/wireless/core.c new file +2 -0

+MODULE_AUTHOR("Johannes Berg");
+MODULE_LICENSE("GPL");

Can you please add a MODULE_DESCRIPTION aswell?

Sure. Then again, didn't you just ask for "why can this be a module at all" too? :)

In London we agreed that it would be good to go ahead and merge cfg80211. This provides some exposure to the API and eases some of the pain for driver maintainers (who won't have to follow wireless-dev to get it). It also adds the ieee80211_ptr to the net_device struct.

I have refactored the cfg80211-related patches down to three patches. This eliminates some of the churn in the series from wireless-dev, and each patch leaves a buildable tree. This version also removes the nl80211 bits to a separate patch (available in wireless-dev on the mm-master branch).