Re: [RFC] Alternate WE-21 support (core API)
On Tue, 2006-09-12 at 09:17 -0700, Jean Tourrilhes wrote: I was initially very negative towards the WPA API (WPA + extended scan), because it's so complex. I went back and forth with Jouni trying to simplify it, but we did not manage to gain much. I trust that Jouni did the best he could, that's just the nature of the beast. :) I was thinking of the WE - nl80211 compatibility. It's pretty trivial to do as far as WE is concerned, you just need to hack get_handler() to return the nl80211 handler. Or, if you don't like a single handler, you could have one wrapper per ioctl, which is even easier. Currently, I don't rely on that at all, nl80211 relies on the driver/stack assigning ieee80211_ptr in the netdevice field and uses that as a cookie. IOW, get_handler() gets to die. My current plan for compatibility was to make all drivers cfg80211-away by making them register themselves with cfg80211 with a callback struct with entries for each thing they need to handle, and then introduce a translation layer that translates incoming WE requests into the appropriate callbacks just like nl80211 translates the incoming genetlink messages. Do you have a recent version of your code so that I can see how it can hook on your side ? I think we could put the generic mechanism in place early so that people can add specifics as they need them. The latest patches were posted to netdev quite a while ago, I haven't done anything with them recently. One thing I'd like to do is rename the include from net/nl80211.h to net/cfg80211.h so that it's more obvious that it isn't purely netlink (include/nl80211.h is the userspace netlink interface so that stays). johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Tue, Sep 12, 2006 at 10:43:57AM +0200, Johannes Berg wrote: But there are bits left and right, so more inspection of drivers would be needed. For example, wavelan and netwave are using encryption key sizes which are not compatible with 802.11. Hmm, interesting. Will need to think about that for a bit. The whole key management stuff is fairly hairy, even more so in wpa/wpa2. I was initially very negative towards the WPA API (WPA + extended scan), because it's so complex. I went back and forth with Jouni trying to simplify it, but we did not manage to gain much. I trust that Jouni did the best he could, that's just the nature of the beast. I was thinking of the WE - nl80211 compatibility. It's pretty trivial to do as far as WE is concerned, you just need to hack get_handler() to return the nl80211 handler. Or, if you don't like a single handler, you could have one wrapper per ioctl, which is even easier. Do you have a recent version of your code so that I can see how it can hook on your side ? I think we could put the generic mechanism in place early so that people can add specifics as they need them. johannes Have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Fri, 2006-09-08 at 09:13 -0700, Jean Tourrilhes wrote: And I don't believe nl80211 will address legacy driver and non-802.11 hardware. It'd help if you'd tell me what in WE specifically addresses non-802.11 legacy hardware. I don't really see anything that is completely orthogonal. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Wed, Sep 06, 2006 at 02:30:53PM -0700, Jean Tourrilhes wrote: On Wed, Sep 06, 2006 at 04:55:44PM -0400, John W. Linville wrote: + * V20 to V21 + * -- + * - Remove (struct net_device *)-get_wireless_stats() + * - Change length in ESSID and NICK to strlen() instead of strlen()+1 + * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers + * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI Personally, I would also add this : + * - Power/Retry relative values no longer * 10 Three reason : 1) It's a cleanup and does not add any new feature 2) It does not change the rest of the patches 3) Userspace part has already gone in distro, not including this bit would mean breaking userspace. Is there any code that corresponds to that? Or does the comment simply indicate policy? The other bits can be included at a later time ;-) Well, maybe. But, I think we should now consider WE to be in maintenance mode. I think nl80211 is the future, as long as Johannes delivers. Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Fri, Sep 08, 2006 at 10:29:23AM -0400, John W. Linville wrote: On Wed, Sep 06, 2006 at 02:30:53PM -0700, Jean Tourrilhes wrote: On Wed, Sep 06, 2006 at 04:55:44PM -0400, John W. Linville wrote: + * V20 to V21 + * -- + * - Remove (struct net_device *)-get_wireless_stats() + * - Change length in ESSID and NICK to strlen() instead of strlen()+1 + * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers + * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI Personally, I would also add this : + * - Power/Retry relative values no longer * 10 Three reason : 1) It's a cleanup and does not add any new feature 2) It does not change the rest of the patches 3) Userspace part has already gone in distro, not including this bit would mean breaking userspace. Is there any code that corresponds to that? Or does the comment simply indicate policy? There is no code in the core of the WE, so it only indicates policy. But, I believe policy change need to be documented. On the other hand you will find code in the tiacx patch. The other bits can be included at a later time ;-) Well, maybe. But, I think we should now consider WE to be in maintenance mode. I think nl80211 is the future, as long as Johannes delivers. We'll see. WE has been supposed to be replaced any time soon for the last 3 years. And I don't believe nl80211 will address legacy driver and non-802.11 hardware. Thanks, John Thanks, and have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Fri, Sep 08, 2006 at 09:13:45AM -0700, Jean Tourrilhes wrote: On Fri, Sep 08, 2006 at 10:29:23AM -0400, John W. Linville wrote: On Wed, Sep 06, 2006 at 02:30:53PM -0700, Jean Tourrilhes wrote: On Wed, Sep 06, 2006 at 04:55:44PM -0400, John W. Linville wrote: + * V20 to V21 + * -- + * - Remove (struct net_device *)-get_wireless_stats() + * - Change length in ESSID and NICK to strlen() instead of strlen()+1 + * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers + * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI Personally, I would also add this : + * - Power/Retry relative values no longer * 10 Three reason : 1) It's a cleanup and does not add any new feature 2) It does not change the rest of the patches 3) Userspace part has already gone in distro, not including this bit would mean breaking userspace. Is there any code that corresponds to that? Or does the comment simply indicate policy? There is no code in the core of the WE, so it only indicates policy. But, I believe policy change need to be documented. On the other hand you will find code in the tiacx patch. Fair enough... Any objections? --- This is version 21 of the Wireless Extensions. Changelog : o finishes migrating the ESSID API (remove the +1) o netdev-get_wireless_stats is no more o long/short retry This is a redacted version of a patch originally submitted by Jean Tourrilhes. I removed most of the additions, in order to minimize future support requirements for nl80211 (or other WE successor). CC: Jean Tourrilhes [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] --- include/linux/netdevice.h |1 - include/linux/wireless.h | 23 +-- net/core/net-sysfs.c |5 +-- net/core/wireless.c | 67 - 4 files changed, 61 insertions(+), 35 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 50a4719..91dc36c 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -334,7 +334,6 @@ #define NETIF_F_ALL_CSUM(NETIF_F_IP_CSU struct net_device_stats* (*get_stats)(struct net_device *dev); - struct iw_statistics* (*get_wireless_stats)(struct net_device *dev); /* List of functions to handle Wireless Extensions (instead of ioctl). * See net/iw_handler.h for details. Jean II */ diff --git a/include/linux/wireless.h b/include/linux/wireless.h index 1358856..7a5860f 100644 --- a/include/linux/wireless.h +++ b/include/linux/wireless.h @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 20 17.2.06 + * Version : 21 14.3.06 * * Authors : Jean Tourrilhes - HPL - [EMAIL PROTECTED] * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved. @@ -69,9 +69,14 @@ #define _LINUX_WIRELESS_H /* INCLUDES */ +/* This header is used in user-space, therefore need to be sanitised + * for that purpose. Those includes are usually not compatible with glibc. + * To know which includes to use in user-space, check iwlib.h. */ +#ifdef __KERNEL__ #include linux/types.h /* for caddr_t et al */ #include linux/socket.h /* for struct sockaddr et al */ #include linux/if.h /* for IFNAMSIZ and co... */ +#endif /* __KERNEL__ */ /* VERSION */ /* @@ -80,7 +85,7 @@ #include linux/if.h /* for IFNAMSIZ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 20 +#define WIRELESS_EXT 21 /* * Changes : @@ -208,6 +213,14 @@ #define WIRELESS_EXT 20 * V19 to V20 * -- * - RtNetlink requests support (SET/GET) + * + * V20 to V21 + * -- + * - Remove (struct net_device *)-get_wireless_stats() + * - Change length in ESSID and NICK to strlen() instead of strlen()+1 + * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers + * - Power/Retry relative values no longer * 10 + * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI */ / CONSTANTS / @@ -448,6 +460,7 @@ #define IW_QUAL_DBM 0x08/* Level + Noi #define IW_QUAL_QUAL_INVALID 0x10/* Driver doesn't provide value */ #define IW_QUAL_LEVEL_INVALID 0x20 #define IW_QUAL_NOISE_INVALID 0x40 +#define IW_QUAL_RCPI 0x80/* Level + Noise are 802.11k RCPI */ #define IW_QUAL_ALL_INVALID0x70 /* Frequency flags */ @@ -500,10 +513,12 @@ #define IW_RETRY_ON 0x /* No detail #define IW_RETRY_TYPE 0xF000 /* Type of parameter */
Re: [RFC] Alternate WE-21 support (core API)
On Wed, 2006-09-06 at 16:55 -0400, John W. Linville wrote: Is this patch acceptable to the group? Does it make things better? Or worse? Did I leave-out anything that should still go in? Did I take too much? Looks good to me. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Wednesday 06 September 2006 22:55, John W. Linville wrote: On Thu, Aug 31, 2006 at 04:00:05PM +0200, Johannes Berg wrote: On Thu, 2006-08-31 at 06:51 -0700, Jouni Malinen wrote: I don't know about the others, but long/short retry limits have users (e.g., Host AP driver) and these drivers are currently forced to use a hack to do this without this cleanup. Furthermore, this part does not add a new ioctl. It does, however, add new parameters and things that'd need to be translated in the compat layer later. Hence, even there, I'd prefer to add them directly into nl80211. However, the compat code for that shouldn't be that bad, so I can see that as a softer target :) But I don't want to see new ioctls for sure. OK, I think we all agree that there are good parts to Jean's WE-21 patch. Below I've made an attempt to separate the wheat from the chaff (or to cut the baby in half)... Is this patch acceptable to the group? Does it make things better? Or worse? Did I leave-out anything that should still go in? Did I take too much? Let me know what you think...? I am OK with this. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
On Wed, Sep 06, 2006 at 04:55:44PM -0400, John W. Linville wrote: On Thu, Aug 31, 2006 at 04:00:05PM +0200, Johannes Berg wrote: On Thu, 2006-08-31 at 06:51 -0700, Jouni Malinen wrote: I don't know about the others, but long/short retry limits have users (e.g., Host AP driver) and these drivers are currently forced to use a hack to do this without this cleanup. Furthermore, this part does not add a new ioctl. It does, however, add new parameters and things that'd need to be translated in the compat layer later. Hence, even there, I'd prefer to add them directly into nl80211. However, the compat code for that shouldn't be that bad, so I can see that as a softer target :) But I don't want to see new ioctls for sure. OK, I think we all agree that there are good parts to Jean's WE-21 patch. Below I've made an attempt to separate the wheat from the chaff (or to cut the baby in half)... Wow, some progress instead of empty talks ! I fully appreciate your effort in moving forward on this issue... Is there anything I can do to help you ? The driver patches should be straighforward as they don't use any of the features you dropped (those patches using the new features were not sent to you to be more precise). Is this patch acceptable to the group? Does it make things better? Or worse? Did I leave-out anything that should still go in? Did I take too much? Let me know what you think...? As far as I can see, your patch looks technically correct. John + * V20 to V21 + * -- + * - Remove (struct net_device *)-get_wireless_stats() + * - Change length in ESSID and NICK to strlen() instead of strlen()+1 + * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers + * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI Personally, I would also add this : + * - Power/Retry relative values no longer * 10 Three reason : 1) It's a cleanup and does not add any new feature 2) It does not change the rest of the patches 3) Userspace part has already gone in distro, not including this bit would mean breaking userspace. The other bits can be included at a later time ;-) Thanks, and have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Alternate WE-21 support (core API)
John W. Linville wrote: On Thu, Aug 31, 2006 at 04:00:05PM +0200, Johannes Berg wrote: On Thu, 2006-08-31 at 06:51 -0700, Jouni Malinen wrote: I don't know about the others, but long/short retry limits have users (e.g., Host AP driver) and these drivers are currently forced to use a hack to do this without this cleanup. Furthermore, this part does not add a new ioctl. It does, however, add new parameters and things that'd need to be translated in the compat layer later. Hence, even there, I'd prefer to add them directly into nl80211. However, the compat code for that shouldn't be that bad, so I can see that as a softer target :) But I don't want to see new ioctls for sure. OK, I think we all agree that there are good parts to Jean's WE-21 patch. Below I've made an attempt to separate the wheat from the chaff (or to cut the baby in half)... Is this patch acceptable to the group? Does it make things better? Or worse? Did I leave-out anything that should still go in? Did I take too much? Let me know what you think...? + * + * The issue : wireless_send_event() is often called in interrupt context, + * while the Netlink layer can never be called in interrupt context. + * The fully formed RtNetlink events are queued, and then a tasklet is run + * to feed those to Netlink. + * The skb_queue is interrupt safe, and its lock is not held while calling + * Netlink, so there is no possibility of dealock. ^^^ You might as well fix the typo now. Otherwise, it looks OK to me. I've been running the original patch for several days with no problems. I don't think you removed anything essential. Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
