ipw2200: version string rework
Subsystems (3)
PATCH 12/18 ipw2200: version string rework
Added version string fields so the version string indicates what is configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot (Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
---
drivers/net/wireless/ipw2200.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 38 insertions(+), 1 deletions(-)
c6f5917d6d8a5a5c44d1386a5ca52b1670ba09cb
drivers/net/wireless/ipw2200.c +38 -1
@@ -33,7 +33,44 @@#include "ipw2200.h" #include <linux/version.h> -#define IPW2200_VERSION "git-1.1.1" + +#ifndef KBUILD_EXTMOD +#define VK "k" +#else +#define VK +#endif + +#ifdef CONFIG_IPW2200_DEBUG +#define VD "d" +#else +#define VD +#endif + +#ifdef CONFIG_IPW2200_MONITOR +#define VM "m" +#else +#define VM +#endif + +#ifdef CONFIG_IPW2200_PROMISCUOUS +#define VP "p" +#else +#define VP +#endif + +#ifdef CONFIG_IEEE80211_RADIOTAP +#define VR "r" +#else +#define VR +#endif + +#ifdef CONFIG_IPW2200_QOS +#define VQ "q" +#else +#define VQ +#endif + +#define IPW2200_VERSION "1.1.1" VK VD VM VP VR VQ#define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2200/2915 Network Driver"#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"#define DRV_VERSION IPW2200_VERSION
Signature · 1 line
1.2.6
Quoted 3 lines · On Thu, 13 Apr 2006 17:20:34 +0800 Zhu Yi <[email protected]> wrote:
Added version string fields so the version string indicates what is configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot (Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
No, this is completely the wrong direction.
Stop with the config option nonsense. It makes it impossible for linux distributions and others that want to ship one kernel and modules.
Quoted 9 lines · Stephen Hemminger
Quoted 3 lines · On Thu, 13 Apr 2006 17:20:34 +0800 Zhu Yi <[email protected]> wrote:
Added version string fields so the version string indicates what is configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot (Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
Quoted 4 lines
No, this is completely the wrong direction.
Stop with the config option nonsense. It makes it impossible for linux distributions and others that want to ship one kernel and modules.
How does it make it impossible for someone to ship one kernel?
There are are various configuration options to enable, some of which are experimental and/or unstable, some add code and/or impact performance when enabled, etc. Not all users want all features.
Easily determining what is enabled in the driver is a requirement.
The distributors should default to not enabling any feature that does not default to =y or =m in Kconfig. In the default configuration, there shouldn't be any post-fix fields appended to the version string. If there is, we need to either fix the version string or the default Kconfig setting.
Is there an alternative method for quickly and easily determining what all features are enabled in a module--even if the module isn't loaded? We didn't see one, and using the fields post-fixed to the version string has quickly resolved various support issues.
Thanks,
James
Quoted 29 lines · On Mon, 17 Apr 2006 11:31:42 -0500 James Ketrenos <[email protected]>…
Quoted 9 lines · Stephen Hemminger
Quoted 3 lines · On Thu, 13 Apr 2006 17:20:34 +0800 Zhu Yi <[email protected]> wrote:
Added version string fields so the version string indicates what is configured (ie, you'll see 1.1.1kpmd if you are using a GIT snapshot (Kernel.. previously -git), promiscuous (p), monitor (m), debug (d) build.
Quoted 4 lines
No, this is completely the wrong direction.
Stop with the config option nonsense. It makes it impossible for linux distributions and others that want to ship one kernel and modules.
How does it make it impossible for someone to ship one kernel?
There are are various configuration options to enable, some of which are experimental and/or unstable, some add code and/or impact performance when enabled, etc. Not all users want all features.
Easily determining what is enabled in the driver is a requirement.
The distributors should default to not enabling any feature that does not default to =y or =m in
Kconfig. In the default configuration, there shouldn't be any post-fix fields appended to the version string. If there is, we need to either fix the version string or the defaultKconfigsetting.
Quoted 7 lines
Is there an alternative method for quickly and easily determining what all features are enabled in a module--even if the module isn't loaded? We didn't see one, and using the fields post-fixed to the version string has quickly resolved various support issues.
Thanks,
James
The version string is good idea, it is just the NxM complexity of possibilities that gets nasty. Also, is this a permanent fixture of these drivers, or just some transitional stage as new features get added that aren't stable yet?