From: James K. <jke...@li...> - 2005-09-13 23:36:05
|
Updated misc. copyright dates. Added version reporting to syslog during ieee80211 subsystem load. Signed-off-by: James Ketrenos <jke...@li...> --- include/net/ieee80211.h | 9 ++++++++- net/ieee80211/ieee80211_module.c | 26 +++++++++++++++++++------- net/ieee80211/ieee80211_rx.c | 2 +- net/ieee80211/ieee80211_tx.c | 2 +- net/ieee80211/ieee80211_wx.c | 2 +- 5 files changed, 30 insertions(+), 11 deletions(-) 051cc01016cb6188fb825ec4f4e7783ac59db64b diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h --- a/include/net/ieee80211.h +++ b/include/net/ieee80211.h @@ -11,12 +11,17 @@ * * Adaption to a generic IEEE 802.11 stack by James Ketrenos * <jke...@li...> - * Copyright (c) 2004, Intel Corporation + * Copyright (c) 2004-2005, Intel Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. See README and COPYING for * more details. + * + * API Version History + * 1.0.x -- Initial version + * 1.1.x -- Added radiotap, QoS, TIM, ieee80211_geo APIs, and + * various structure changes */ #ifndef IEEE80211_H #define IEEE80211_H @@ -24,6 +29,8 @@ #include <linux/kernel.h> /* ARRAY_SIZE */ #include <linux/wireless.h> +#define IEEE80211_VERSION "git-1.1.4-pre5" + #ifdef CONFIG_IEEE80211_CRYPT_TKIP_MODULE #ifndef CONFIG_IEEE80211_CRYPT_TKIP #define CONFIG_IEEE80211_CRYPT_TKIP diff --git a/net/ieee80211/ieee80211_module.c b/net/ieee80211/ieee80211_module.c --- a/net/ieee80211/ieee80211_module.c +++ b/net/ieee80211/ieee80211_module.c @@ -1,6 +1,6 @@ /******************************************************************************* - Copyright(c) 2004 Intel Corporation. All rights reserved. + Copyright(c) 2004-2005 Intel Corporation. All rights reserved. Portions of this file are based on the WEP enablement code provided by the Host AP project hostap-drivers v0.1.3 @@ -53,13 +53,16 @@ #include <net/ieee80211.h> -MODULE_DESCRIPTION("802.11 data/management/control stack"); -MODULE_AUTHOR - ("Copyright (C) 2004 Intel Corporation <jke...@li...>"); +#define DRV_DESCRIPTION "802.11 data/management/control stack" +#define DRV_NAME "ieee80211" +#define DRV_VERSION IEEE80211_VERSION +#define DRV_COPYRIGHT "Copyright (C) 2004-2005 Intel Corporation <jke...@li...>" + +MODULE_VERSION(DRV_VERSION); +MODULE_DESCRIPTION(DRV_DESCRIPTION); +MODULE_AUTHOR(DRV_COPYRIGHT); MODULE_LICENSE("GPL"); -#define DRV_NAME "ieee80211" - static inline int ieee80211_networks_allocate(struct ieee80211_device *ieee) { if (ieee->networks) @@ -218,9 +221,11 @@ static int store_debug_level(struct file return strnlen(buf, len); } +#endif /* CONFIG_IEEE80211_DEBUG */ static int __init ieee80211_init(void) { +#ifdef CONFIG_IEEE80211_DEBUG struct proc_dir_entry *e; ieee80211_debug_level = debug; @@ -240,26 +245,33 @@ static int __init ieee80211_init(void) e->read_proc = show_debug_level; e->write_proc = store_debug_level; e->data = NULL; +#endif /* CONFIG_IEEE80211_DEBUG */ + + printk(KERN_INFO DRV_NAME ": " DRV_DESCRIPTION ", " DRV_VERSION "\n"); + printk(KERN_INFO DRV_NAME ": " DRV_COPYRIGHT "\n"); return 0; } static void __exit ieee80211_exit(void) { +#ifdef CONFIG_IEEE80211_DEBUG if (ieee80211_proc) { remove_proc_entry("debug_level", ieee80211_proc); remove_proc_entry(DRV_NAME, proc_net); ieee80211_proc = NULL; } +#endif /* CONFIG_IEEE80211_DEBUG */ } +#ifdef CONFIG_IEEE80211_DEBUG #include <linux/moduleparam.h> module_param(debug, int, 0444); MODULE_PARM_DESC(debug, "debug output mask"); +#endif /* CONFIG_IEEE80211_DEBUG */ module_exit(ieee80211_exit); module_init(ieee80211_init); -#endif const char *escape_essid(const char *essid, u8 essid_len) { diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c --- a/net/ieee80211/ieee80211_rx.c +++ b/net/ieee80211/ieee80211_rx.c @@ -5,7 +5,7 @@ * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen * <jkm...@cc...> * Copyright (c) 2002-2003, Jouni Malinen <jkm...@cc...> - * Copyright (c) 2004, Intel Corporation + * Copyright (c) 2004-2005, Intel Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c --- a/net/ieee80211/ieee80211_tx.c +++ b/net/ieee80211/ieee80211_tx.c @@ -1,6 +1,6 @@ /****************************************************************************** - Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as diff --git a/net/ieee80211/ieee80211_wx.c b/net/ieee80211/ieee80211_wx.c --- a/net/ieee80211/ieee80211_wx.c +++ b/net/ieee80211/ieee80211_wx.c @@ -1,6 +1,6 @@ /****************************************************************************** - Copyright(c) 2004 Intel Corporation. All rights reserved. + Copyright(c) 2004-2005 Intel Corporation. All rights reserved. Portions of this file are based on the WEP enablement code provided by the Host AP project hostap-drivers v0.1.3 |
From: Christoph H. <hc...@in...> - 2005-09-14 10:54:23
|
On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > Updated misc. copyright dates. > Added version reporting to syslog during ieee80211 subsystem load. version reporting for subsystems doesn't make sense - they evolve too much and should evolve with the kernel tree, not separately. |
From: James K. <jke...@li...> - 2005-09-14 17:16:20
|
Christoph Hellwig wrote: >On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > > >>Updated misc. copyright dates. >>Added version reporting to syslog during ieee80211 subsystem load. >> >> > >version reporting for subsystems doesn't make sense - they evolve too much >and should evolve with the kernel tree, not separately. > > Do you have issue with reporting the version via printk, or just -having- versioning? If the former, its a useful debug and troubleshooting tool, and the overhead is minimal. There are other ways to get at the info (modinfo) but displaying the version information via printk it is used by other components in the kernel. James |
From: Christoph H. <hc...@in...> - 2005-09-17 09:28:55
|
On Wed, Sep 14, 2005 at 12:16:15PM -0500, James Ketrenos wrote: > Christoph Hellwig wrote: > > >On Tue, Sep 13, 2005 at 06:35:57PM -0500, James Ketrenos wrote: > > > > > >>Updated misc. copyright dates. > >>Added version reporting to syslog during ieee80211 subsystem load. > >> > >> > > > >version reporting for subsystems doesn't make sense - they evolve too much > >and should evolve with the kernel tree, not separately. > > > > > Do you have issue with reporting the version via printk, or just > -having- versioning? > > If the former, its a useful debug and troubleshooting tool, and the > overhead is minimal. There are other ways to get at the info (modinfo) > but displaying the version information via printk it is used by other > components in the kernel. I mean not having versioning at all. The kernel version should uniqueuely identify major subsystems, not a version of it's own. Development will happen in the kernel tree anyway, and you should better start submitting patches often and early or you will get ouf of sync with all the development going on in mainline. That early and often thing is true for drivers aswell, the intel wireless driver are so hopelessly out of date in mainline just after submission that it's not funny anymore. Hopefully we'll have a mainline maintainer for them soon that imports everything important from intel and other contributors. |
From: Jeff G. <jg...@po...> - 2005-09-19 01:13:19
|
Christoph Hellwig wrote: > I mean not having versioning at all. The kernel version should uniqueuely > identify major subsystems, not a version of it's own. Development will > happen in the kernel tree anyway, and you should better start submitting > patches often and early or you will get ouf of sync with all the development > going on in mainline. Maintainer's choice. > That early and often thing is true for drivers aswell, the intel wireless > driver are so hopelessly out of date in mainline just after submission that > it's not funny anymore. Hopefully we'll have a mainline maintainer for > them soon that imports everything important from intel and other contributors. Patience: We still have over 20 patches to merge, before even getting to the ipw updates. Jeff |
From: Michael Wu <fla...@so...> - 2005-09-19 04:45:08
|
Quoting Jeff Garzik <jg...@po...>: > Christoph Hellwig wrote: >> I mean not having versioning at all. The kernel version should uniqueuely >> identify major subsystems, not a version of it's own. Development will >> happen in the kernel tree anyway, and you should better start submitting >> patches often and early or you will get ouf of sync with all the development >> going on in mainline. > > Maintainer's choice. > > If it has a version, then only the maintainer can submit patches - otherwise the version is useless for identifying what code you're running. (unless other submitters decide to alter the version too, which is probably not a good idea) >> That early and often thing is true for drivers aswell, the intel wireless >> driver are so hopelessly out of date in mainline just after submission that >> it's not funny anymore. Hopefully we'll have a mainline maintainer for >> them soon that imports everything important from intel and other >> contributors. > > Patience: We still have over 20 patches to merge, before even getting > to the ipw updates. > I wish those patches were submitted and merged quickly when they were created instead of piling up. Other people can't get patches merged because it would break the chain of patches. Patches are being sent too late and infrequently.. -Michael Wu |
From: Jeff G. <jg...@po...> - 2005-09-19 05:41:31
|
Michael Wu wrote: > If it has a version, then only the maintainer can submit patches - False. Presence of an optional label in source code files does not change the fundamental rules of open source, or the processes surrounding patch merging in the Linux kernel. Anybody who feels the version number should be changed is welcome to submit a patch. And a reviewer along the line is welcome to reject such a patch, if they think it is unwarranted. > otherwise the > version is useless for identifying what code you're running. (unless other False. We have plenty of examples of slower-moving drivers where community consensus often dictates a version number change. > submitters decide to alter the version too, which is probably not a good > idea) For any given driver/subsystem/whatever version number in the kernel, ultimately a submittor changes the version and one or more reviewers approve this, by pulling the change into their tree. Your "probably not a good idea" is the 100% case here, including the master version number in ./Makefile. >>> That early and often thing is true for drivers aswell, the intel >>> wireless >>> driver are so hopelessly out of date in mainline just after >>> submission that >>> it's not funny anymore. Hopefully we'll have a mainline maintainer for >>> them soon that imports everything important from intel and other >>> contributors. >> >> >> Patience: We still have over 20 patches to merge, before even getting >> to the ipw updates. >> > I wish those patches were submitted and merged quickly when they were > created > instead of piling up. Other people can't get patches merged because it Agreed. > Other people can't get patches merged because it > would > break the chain of patches. Patches are being sent too late and > and infrequently.. Patience. We've got to balance kernel hackers' insatiable desire for cleanups, with the desire of users and driver developers to move forward with Linux wireless support. Since Intel has useful stuff, stuff which affects a wide range of hardware owned by Linux users, it's worth waiting a bit to let them catch up. Of course, if it takes forever to merge their stuff, someone else will inevitably come along and speed up the process. Open source at work. Currently, it has rather been like a clock algorithm: merge initial ieee80211 code from Intel. Accept months worth of cleanups from community. Accept unifying updates from Jouni. Begin merging work from Jiri and SuSE. Now the clock hand points at Intel again, and they've been waiting a while to send useful stuff. People are slowly converging at a decent solution, while at the same moving wireless hardware support forward. The need to improve the wireless API is balanced with the need to keep wireless hardware working (and/or enable new wireless hardware). This convergence will be attained more rapidly once the community starts WORKING TOGETHER, rather than sending me competing patches. Person A breaks Person B's work. And then back again. Jeff |
From: Matt D. <Mat...@de...> - 2005-09-19 22:01:11
|
On Mon, Sep 19, 2005 at 01:41:14AM -0400, Jeff Garzik wrote: > Michael Wu wrote: > >If it has a version, then only the maintainer can submit patches - > > False. Presence of an optional label in source code files does not > change the fundamental rules of open source, or the processes > surrounding patch merging in the Linux kernel. Anybody who feels the > version number should be changed is welcome to submit a patch. And a > reviewer along the line is welcome to reject such a patch, if they think > it is unwarranted. > > >otherwise the > >version is useless for identifying what code you're running. (unless other > > False. We have plenty of examples of slower-moving drivers where > community consensus often dictates a version number change. This is also the reason for the 'srcversion' field available in modinfo. This is a CRC across the source code for a given module (not counting #include<*>, but counting #include "*"). The version field may not change, but if anything really cares about a particular source code copy, and that it hasn't been patched, but the version field not updated, they can see that. Thanks to Rusty for implementing this. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com |
From: Michael Wu <fla...@so...> - 2005-09-21 03:28:55
|
On Monday 19 September 2005 01:41, Jeff Garzik wrote: > Patience. We've got to balance kernel hackers' insatiable desire for > cleanups, with the desire of users and driver developers to move forward > with Linux wireless support. > > Since Intel has useful stuff, stuff which affects a wide range of > hardware owned by Linux users, it's worth waiting a bit to let them > catch up. Of course, if it takes forever to merge their stuff, someone > else will inevitably come along and speed up the process. Open source > at work. > I don't have the patience to wait forever. Mind if I speed up the process? The following patch series contains all the unapplied patches up to #17 from James Ketrenos' patch series with fixes for all the issues raised last time. I will finish the rest of the patch series if this is applied. Some patches were consolidated. This patch series is against the netdev upstream branch. Thanks, -Michael Wu |