Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
> This all began (AFAIK) because some of us want to continue to be
> able to specify ARCH={i386,x86_64} on the (make) command line --
> not by using a .config file. Taking away ARCH= on the command line
> is a regression (in some minds, at least), so Sam provided that
> capability. Is that capability still present after this patch?
My patch does exactly that.
Sam's patch only made a subtle difference for all*config, but otherwise it
would have made little difference, i.e. you still had to edit .config.
The maybe only remaining issue is which default config to use for
defconfig, when ARCH isn't specified, but that is purely a Kbuild issue.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Fri, 16 Nov 2007, Sam Ravnborg wrote: > 1) make all*config, randconfig, defconfig is broken on 64-bit boxes With your approach you made it impossible to set 64BIT from all*.config, which is the proper way to set the defaults. > 2) A pure code refactoring patch is reverted for no obvious reason It was done for the wrong reasons, otherwise the warning before it should have been included as well and then the function could have been reused for the "# ... is not set" case as well. > 3) Behavioral changes are not documented: >- 32-bit/64-bit can only be selected in config is you specify ARCH=x86 Which is now the default and thus it behaves more like other archs. >- ARCH= takes precedence over kernel config for a configured kernel What point is there in being able to specify ARCH=x86_64 and then still produce a 32bit kernel? > 4) The changelogs miss title on reverted patches Seriously? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Fri, 16 Nov 2007, Sam Ravnborg wrote: 1) make all*config, randconfig, defconfig is broken on 64-bit boxes With your approach you made it impossible to set 64BIT from all*.config, which is the proper way to set the defaults. 2) A pure code refactoring patch is reverted for no obvious reason It was done for the wrong reasons, otherwise the warning before it should have been included as well and then the function could have been reused for the # ... is not set case as well. 3) Behavioral changes are not documented: - 32-bit/64-bit can only be selected in config is you specify ARCH=x86 Which is now the default and thus it behaves more like other archs. - ARCH= takes precedence over kernel config for a configured kernel What point is there in being able to specify ARCH=x86_64 and then still produce a 32bit kernel? 4) The changelogs miss title on reverted patches Seriously? bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam provided that
capability. Is that capability still present after this patch?
My patch does exactly that.
Sam's patch only made a subtle difference for all*config, but otherwise it
would have made little difference, i.e. you still had to edit .config.
The maybe only remaining issue is which default config to use for
defconfig, when ARCH isn't specified, but that is purely a Kbuild issue.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman.
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64}, otherwise it's set by the user:
Just eyeballing your patch I made following observations:
1) make all*config, randconfig, defconfig is broken on 64-bit boxes
2) A pure code refactoring patch is reverted for no obvious reason
3) Behavioral changes are not documented:
- 32-bit/64-bit can only be selected in config is you specify ARCH=x86
- ARCH= takes precedence over kernel config for a configured kernel
4) The changelogs miss title on reverted patches
All points are trivial to fix so I do not say your approach is
bad - just that the supplied patch is not good enough.
I will fix it up tonight and test it.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
> Hi,
>
> On Thu, 15 Nov 2007, Sam Ravnborg wrote:
>
> > You suggest just to check ARCH value and not apply your patch. This was
> > not my initial understanding as was hopefully obvious from my reply.
>
> This patch only adds some extra features.
>
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64}, otherwise it's set by the user:
Roman,
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam provided that
capability. Is that capability still present after this patch?
Thanks.
> bye, Roman
>
> Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
>
> ---
> Makefile |3 ++-
> arch/x86/Kconfig |4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/Makefile
> ===
> --- linux-2.6.orig/Makefile
> +++ linux-2.6/Makefile
> @@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
> # then ARCH is assigned, getting whatever value it gets normally, and
> # SUBARCH is subsequently ignored.
>
> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> + -e s/sun4u/sparc64/ \
> -e s/arm.*/arm/ -e s/sa110/arm/ \
> -e s/s390x/s390/ -e s/parisc64/parisc/ \
> -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> Index: linux-2.6/arch/x86/Kconfig
> ===
> --- linux-2.6.orig/arch/x86/Kconfig
> +++ linux-2.6/arch/x86/Kconfig
> @@ -3,8 +3,8 @@ mainmenu "Linux Kernel Configuration for
>
> # Select 32 or 64 bit
> config 64BIT
> - bool "64-bit kernel"
> - default n
> + bool "64-bit kernel" if ARCH="x86"
> + default ARCH="x86_64"
> help
> Say yes to build a 64-bit kernel - formerly known as x86_64
> Say no to build a 32-bit kernel - formerly known as i386
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> You suggest just to check ARCH value and not apply your patch. This was
> not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
> If user did NOT specify ARCH we should use the kernel configuration - which
> your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile |3 ++-
arch/x86/Kconfig |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -3,8 +3,8 @@ mainmenu "Linux Kernel Configuration for
# Select 32 or 64 bit
config 64BIT
- bool "64-bit kernel"
- default n
+ bool "64-bit kernel" if ARCH="x86"
+ default ARCH="x86_64"
help
Say yes to build a 64-bit kernel - formerly known as x86_64
Say no to build a 32-bit kernel - formerly known as i386Revert
9c900a9c9d9351e55ab6a84e12e3a52c474c7c8b
0f855aa64b3f63d35a891510cf7db932a435c116
2a113281f5cd2febbab21a93c8943f8d3eece4d3
and K64BIT parts of
daa93fab824f2b8c35bd11670c7fab2f32b2de5f
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile|4 -
README |2
scripts/kconfig/conf.c |1
scripts/kconfig/confdata.c | 146
scripts/kconfig/lkc_proto.h |1
5 files changed, 56 insertions(+), 98 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -200,11 +200,9 @@ SRCARCH:= $(ARCH)
# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
SRCARCH := x86
-K64BIT := n
endif
ifeq ($(ARCH),x86_64)
SRCARCH := x86
-K64BIT := y
endif
KCONFIG_CONFIG ?= .config
@@ -341,7 +339,7 @@ KERNELRELEASE = $(shell cat include/conf
KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-export ARCH SRCARCH K64BIT CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD
CC
+export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
Index: linux-2.6/README
===
--- linux-2.6.orig/README
+++ linux-2.6/README
@@ -194,8 +194,6 @@ CONFIGURING the kernel:
"make *config" checks for a file named "all{yes/mod/no/random}.config"
for symbol values that are to be forced. If this file is not found,
it checks for a file named "all.config" to contain forced values.
- Finally it checks the environment variable K64BIT and if found, sets
- the config symbol "64BIT" to the value of the K64BIT variable.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
Index: linux-2.6/scripts/kconfig/conf.c
===
--- linux-2.6.orig/scripts/kconfig/conf.c
+++ linux-2.6/scripts/kconfig/conf.c
@@ -591,7 +591,6 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat("all.config", ))
conf_read_simple("all.config", S_DEF_USER);
- conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
break;
default:
break;
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -83,95 +83,6 @@ char *conf_get_default_confname(void)
return name;
}
-static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char
*p)
-{
- char *p2;
-
-
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Thu, Nov 15, 2007 at 10:24:05PM +0100, Roman Zippel wrote: > Hi, > > On Thu, 15 Nov 2007, Sam Ravnborg wrote: > > > > Can we please can get some consistency in this? > > > We have a .config file for a reason, what's wrong with using it? > > > > We need to set a selected few values in a few cases where we do > > not have a .config file. > > allmodconfig for x86 for instance. We would like to generate a > > 32-bit and a 64-bit version. > > This can already be set via all.config/allmod.config. > Where is this need coming from? The point is that I don't like to add an > interface, which is maybe used by two people, who should be perfectly > capable using an existing superior mechanism. When you say "two people" I am afraid we are not talking about the same case. > > > > > > Please revert the K64BIT changes and use this instead. > > > > > > > > I will finish up your patch and target it for next merge window. > > > > > > Why can't this be fixed properly now? You don't even need this patch, > > > just > > > use ARCH to set 64BIT in the Kconfig as I've shown. > > Because the patch is in mainline and has been tested by a lot of people > > during the last week. And as the functionality is almost equal I do not > > see it as a big deal to have the less-perfect solution in one kernel > > release. > > > > And the only reason the patch were applied to mainline was to fix the build > > of the merged x86 architecute - otherwise it was in no way -rc material. > > I showed you a solution, which requires no patch at all, while your patch > adds extra functionality which is questionable. > Why is a quick hack preferable over a proper solution? > Either explain why my solution isn't usable or _please_ revert the K64BIT > changes. You suggest just to check ARCH value and not apply your patch. This was not my initial understanding as was hopefully obvious from my reply. So you suggest to make the ARCH= setting on the command line mandatory again even for a configured kernel which is a step backward. I assume your patch also has this drawback - no? If user did NOT specify ARCH we should use the kernel configuration - which your solution fail to do. If user did specify ARCH and the kernel is configured then what? -> Ignore the ARCH= setting -> Warn if they do not match -> Always adhere to the ARCH setting Accepting the solution where we check the ARCH as you suggested and loose the benefits of letting the configuration be the master should be OK for upcoming kernel release. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Thu, 15 Nov 2007, Sam Ravnborg wrote: > > Can we please can get some consistency in this? > > We have a .config file for a reason, what's wrong with using it? > > We need to set a selected few values in a few cases where we do > not have a .config file. > allmodconfig for x86 for instance. We would like to generate a > 32-bit and a 64-bit version. This can already be set via all.config/allmod.config. Where is this need coming from? The point is that I don't like to add an interface, which is maybe used by two people, who should be perfectly capable using an existing superior mechanism. > > > > Please revert the K64BIT changes and use this instead. > > > > > > I will finish up your patch and target it for next merge window. > > > > Why can't this be fixed properly now? You don't even need this patch, just > > use ARCH to set 64BIT in the Kconfig as I've shown. > Because the patch is in mainline and has been tested by a lot of people > during the last week. And as the functionality is almost equal I do not > see it as a big deal to have the less-perfect solution in one kernel release. > > And the only reason the patch were applied to mainline was to fix the build > of the merged x86 architecute - otherwise it was in no way -rc material. I showed you a solution, which requires no patch at all, while your patch adds extra functionality which is questionable. Why is a quick hack preferable over a proper solution? Either explain why my solution isn't usable or _please_ revert the K64BIT changes. > > > > These are two different uses, when reading a .config only the basic > > > > syntax > > > > is checked, but not the value itself. > > > This is wrong considering the amount of people that hand edit the .config > > > file. > > > > It's not, the actual symbol value is set later depending on the dependency > > constraints. > My point is that the .config file is handedited so the syntax should be > checked > to best possible extent. If someone specify CONFIG_64BIT=64 we should error > out. The other function doesn't complain about it either. There is already only limited error checking, e.g. there is no complaint that the value isn't really set (because it was selected by something else), otherwise the .config check during a kernel upgrades would be a lot noisier than it already is. Anyone directly editing .config should know what he is doing. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman. > > > > The value can be supplied on the command-line so we need to validate > > > > input. > > > > > > Is there a need for this? > > Yes. We would like to set 64BIT or not in other than x86 cases. > > And way forward was not to override ARCH as in the x86 case. > > Can we please can get some consistency in this? > We have a .config file for a reason, what's wrong with using it? We need to set a selected few values in a few cases where we do not have a .config file. allmodconfig for x86 for instance. We would like to generate a 32-bit and a 64-bit version. > > > > Please revert the K64BIT changes and use this instead. > > > > I will finish up your patch and target it for next merge window. > > Why can't this be fixed properly now? You don't even need this patch, just > use ARCH to set 64BIT in the Kconfig as I've shown. Because the patch is in mainline and has been tested by a lot of people during the last week. And as the functionality is almost equal I do not see it as a big deal to have the less-perfect solution in one kernel release. And the only reason the patch were applied to mainline was to fix the build of the merged x86 architecute - otherwise it was in no way -rc material. > > > > These are two different uses, when reading a .config only the basic > > > syntax > > > is checked, but not the value itself. > > This is wrong considering the amount of people that hand edit the .config > > file. > > It's not, the actual symbol value is set later depending on the dependency > constraints. My point is that the .config file is handedited so the syntax should be checked to best possible extent. If someone specify CONFIG_64BIT=64 we should error out. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Thu, Nov 15, 2007 at 04:43:03PM +0100, Roman Zippel wrote: > Hi, > > On Wed, 14 Nov 2007, Sam Ravnborg wrote: > > > The value can be supplied on the command-line so we need to validate input. > > Is there a need for this? Yes. We would like to set 64BIT or not in other than x86 cases. And way forward was not to override ARCH as in the x86 case. > BTW ARCH was already available as a value in the Kconfig files, so setting > the 64BIT option was already possible without any changes the kconfig > system, e.g.: > > config 64BIT > bool "64 Bit kernel" if ARCH!="i386" && ARCH!="x86_64" > default ARCH="x86_64" I thought this was not possible but it must have been the limitation of choice symbols I have hit when I played with it. > The patch below adds some features to it: > - it allows to import any environment variable by specifying "option env=..." > - it generates a dependency on it, so the kernel config is updated if it > changes. > > Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Thanks. > > > The code is a copy of what happen when reading a all.config file and > > the functionality should be equal. > > Can we make that part simpler too? > > These are two different uses, when reading a .config only the basic syntax > is checked, but not the value itself. This is wrong considering the amount of people that hand edit the .config file. > > By the way - I have never understood the purpose of the flags (S_DEF_USER > > etc.) > > Can we have a few comments added to their definition? > > It allows to hold multiple configs, a user of it is conf_split_config() > which loads another config and compares to the current config and updates > the files under include/config as needed. > It could also be used by front ends to display what actually changed > compared to e.g. the saved config. Took a deeper look. So we can have 4 different set of vlaues where the value indexed by S_DEF_USER is the one that is actually used and the other three can be used to hold values. I will try to document this in expr.h Patch will be sent to you for review. > > One of the blockers are that kconfig does not support more than one prompt > > for a choice symbol. Is this something you can fix - or sketch how to fix > > it? > > The basic idea is to add a name to the choice, so multiple choices can be > grouped together. This requires some changes to the dependency check to > make sure one choice option doesn't depend on another (which is currently > enforced by the syntax). Do you have any suggestions how to properly fix this? Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Thu, 15 Nov 2007, Sam Ravnborg wrote: > > > The value can be supplied on the command-line so we need to validate > > > input. > > > > Is there a need for this? > Yes. We would like to set 64BIT or not in other than x86 cases. > And way forward was not to override ARCH as in the x86 case. Can we please can get some consistency in this? We have a .config file for a reason, what's wrong with using it? > > Please revert the K64BIT changes and use this instead. > > I will finish up your patch and target it for next merge window. Why can't this be fixed properly now? You don't even need this patch, just use ARCH to set 64BIT in the Kconfig as I've shown. > > These are two different uses, when reading a .config only the basic syntax > > is checked, but not the value itself. > This is wrong considering the amount of people that hand edit the .config > file. It's not, the actual symbol value is set later depending on the dependency constraints. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Wed, 14 Nov 2007, Sam Ravnborg wrote:
> The value can be supplied on the command-line so we need to validate input.
Is there a need for this?
BTW ARCH was already available as a value in the Kconfig files, so setting
the 64BIT option was already possible without any changes the kconfig
system, e.g.:
config 64BIT
bool "64 Bit kernel" if ARCH!="i386" && ARCH!="x86_64"
default ARCH="x86_64"
The patch below adds some features to it:
- it allows to import any environment variable by specifying "option env=..."
- it generates a dependency on it, so the kernel config is updated if it
changes.
Please revert the K64BIT changes and use this instead.
> The code is a copy of what happen when reading a all.config file and
> the functionality should be equal.
> Can we make that part simpler too?
These are two different uses, when reading a .config only the basic syntax
is checked, but not the value itself.
> By the way - I have never understood the purpose of the flags (S_DEF_USER
> etc.)
> Can we have a few comments added to their definition?
It allows to hold multiple configs, a user of it is conf_split_config()
which loads another config and compares to the current config and updates
the files under include/config as needed.
It could also be used by front ends to display what actually changed
compared to e.g. the saved config.
> One of the blockers are that kconfig does not support more than one prompt
> for a choice symbol. Is this something you can fix - or sketch how to fix it?
The basic idea is to add a name to the choice, so multiple choices can be
grouped together. This requires some changes to the dependency check to
make sure one choice option doesn't depend on another (which is currently
enforced by the syntax).
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4 ++
scripts/kconfig/expr.c | 16 +-
scripts/kconfig/expr.h |5 +--
scripts/kconfig/lkc.h|5 +++
scripts/kconfig/menu.c |7 +++-
scripts/kconfig/qconf.cc | 15 ++---
scripts/kconfig/symbol.c | 53 +--
scripts/kconfig/util.c | 25 +++-
scripts/kconfig/zconf.gperf |1
scripts/kconfig/zconf.hash.c_shipped | 45 -
10 files changed, 123 insertions(+), 53 deletions(-)
Index: linux-2.6/init/Kconfig
===
--- linux-2.6.orig/init/Kconfig
+++ linux-2.6/init/Kconfig
@@ -7,6 +7,10 @@ config DEFCONFIG_LIST
default "/boot/config-$UNAME_RELEASE"
default "arch/$ARCH/defconfig"
+config ARCH
+ string
+ option env="ARCH"
+
menu "General setup"
config EXPERIMENTAL
Index: linux-2.6/scripts/kconfig/expr.c
===
--- linux-2.6.orig/scripts/kconfig/expr.c
+++ linux-2.6/scripts/kconfig/expr.c
@@ -87,7 +87,7 @@ struct expr *expr_copy(struct expr *org)
break;
case E_AND:
case E_OR:
- case E_CHOICE:
+ case E_LIST:
e->left.expr = expr_copy(org->left.expr);
e->right.expr = expr_copy(org->right.expr);
break;
@@ -217,7 +217,7 @@ int expr_eq(struct expr *e1, struct expr
expr_free(e2);
trans_count = old_count;
return res;
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -648,7 +648,7 @@ struct expr *expr_transform(struct expr
case E_EQUAL:
case E_UNEQUAL:
case E_SYMBOL:
- case E_CHOICE:
+ case E_LIST:
break;
default:
e->left.expr = expr_transform(e->left.expr);
@@ -932,7 +932,7 @@ struct expr *expr_trans_compare(struct e
break;
case E_SYMBOL:
return expr_alloc_comp(type, e->left.sym, sym);
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -1000,9 +1000,9 @@ int expr_compare_type(enum expr_type t1,
if (t2 == E_OR)
return 1;
case E_OR:
- if (t2 == E_CHOICE)
+ if (t2 == E_LIST)
return 1;
- case E_CHOICE:
+ case E_LIST:
if (t2 == 0)
return 1;
default:
@@ -1053,11 +1053,11 @@ void expr_print(struct expr *e, void (*f
fn(data, NULL, " && ");
expr_print(e->right.expr, fn, data, E_AND);
break;
- case E_CHOICE:
+ case E_LIST:
fn(data, e->right.sym, e->right.sym->name);
if (e->left.expr) {
fn(data, NULL, " ^ ");
- expr_print(e->left.expr, fn,
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Wed, 14 Nov 2007, Sam Ravnborg wrote:
The value can be supplied on the command-line so we need to validate input.
Is there a need for this?
BTW ARCH was already available as a value in the Kconfig files, so setting
the 64BIT option was already possible without any changes the kconfig
system, e.g.:
config 64BIT
bool 64 Bit kernel if ARCH!=i386 ARCH!=x86_64
default ARCH=x86_64
The patch below adds some features to it:
- it allows to import any environment variable by specifying option env=...
- it generates a dependency on it, so the kernel config is updated if it
changes.
Please revert the K64BIT changes and use this instead.
The code is a copy of what happen when reading a all.config file and
the functionality should be equal.
Can we make that part simpler too?
These are two different uses, when reading a .config only the basic syntax
is checked, but not the value itself.
By the way - I have never understood the purpose of the flags (S_DEF_USER
etc.)
Can we have a few comments added to their definition?
It allows to hold multiple configs, a user of it is conf_split_config()
which loads another config and compares to the current config and updates
the files under include/config as needed.
It could also be used by front ends to display what actually changed
compared to e.g. the saved config.
One of the blockers are that kconfig does not support more than one prompt
for a choice symbol. Is this something you can fix - or sketch how to fix it?
The basic idea is to add a name to the choice, so multiple choices can be
grouped together. This requires some changes to the dependency check to
make sure one choice option doesn't depend on another (which is currently
enforced by the syntax).
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
init/Kconfig |4 ++
scripts/kconfig/expr.c | 16 +-
scripts/kconfig/expr.h |5 +--
scripts/kconfig/lkc.h|5 +++
scripts/kconfig/menu.c |7 +++-
scripts/kconfig/qconf.cc | 15 ++---
scripts/kconfig/symbol.c | 53 +--
scripts/kconfig/util.c | 25 +++-
scripts/kconfig/zconf.gperf |1
scripts/kconfig/zconf.hash.c_shipped | 45 -
10 files changed, 123 insertions(+), 53 deletions(-)
Index: linux-2.6/init/Kconfig
===
--- linux-2.6.orig/init/Kconfig
+++ linux-2.6/init/Kconfig
@@ -7,6 +7,10 @@ config DEFCONFIG_LIST
default /boot/config-$UNAME_RELEASE
default arch/$ARCH/defconfig
+config ARCH
+ string
+ option env=ARCH
+
menu General setup
config EXPERIMENTAL
Index: linux-2.6/scripts/kconfig/expr.c
===
--- linux-2.6.orig/scripts/kconfig/expr.c
+++ linux-2.6/scripts/kconfig/expr.c
@@ -87,7 +87,7 @@ struct expr *expr_copy(struct expr *org)
break;
case E_AND:
case E_OR:
- case E_CHOICE:
+ case E_LIST:
e-left.expr = expr_copy(org-left.expr);
e-right.expr = expr_copy(org-right.expr);
break;
@@ -217,7 +217,7 @@ int expr_eq(struct expr *e1, struct expr
expr_free(e2);
trans_count = old_count;
return res;
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -648,7 +648,7 @@ struct expr *expr_transform(struct expr
case E_EQUAL:
case E_UNEQUAL:
case E_SYMBOL:
- case E_CHOICE:
+ case E_LIST:
break;
default:
e-left.expr = expr_transform(e-left.expr);
@@ -932,7 +932,7 @@ struct expr *expr_trans_compare(struct e
break;
case E_SYMBOL:
return expr_alloc_comp(type, e-left.sym, sym);
- case E_CHOICE:
+ case E_LIST:
case E_RANGE:
case E_NONE:
/* panic */;
@@ -1000,9 +1000,9 @@ int expr_compare_type(enum expr_type t1,
if (t2 == E_OR)
return 1;
case E_OR:
- if (t2 == E_CHOICE)
+ if (t2 == E_LIST)
return 1;
- case E_CHOICE:
+ case E_LIST:
if (t2 == 0)
return 1;
default:
@@ -1053,11 +1053,11 @@ void expr_print(struct expr *e, void (*f
fn(data, NULL, );
expr_print(e-right.expr, fn, data, E_AND);
break;
- case E_CHOICE:
+ case E_LIST:
fn(data, e-right.sym, e-right.sym-name);
if (e-left.expr) {
fn(data, NULL, ^ );
- expr_print(e-left.expr, fn, data, E_CHOICE);
+
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Thu, Nov 15, 2007 at 04:43:03PM +0100, Roman Zippel wrote: Hi, On Wed, 14 Nov 2007, Sam Ravnborg wrote: The value can be supplied on the command-line so we need to validate input. Is there a need for this? Yes. We would like to set 64BIT or not in other than x86 cases. And way forward was not to override ARCH as in the x86 case. BTW ARCH was already available as a value in the Kconfig files, so setting the 64BIT option was already possible without any changes the kconfig system, e.g.: config 64BIT bool 64 Bit kernel if ARCH!=i386 ARCH!=x86_64 default ARCH=x86_64 I thought this was not possible but it must have been the limitation of choice symbols I have hit when I played with it. The patch below adds some features to it: - it allows to import any environment variable by specifying option env=... - it generates a dependency on it, so the kernel config is updated if it changes. Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Thanks. The code is a copy of what happen when reading a all.config file and the functionality should be equal. Can we make that part simpler too? These are two different uses, when reading a .config only the basic syntax is checked, but not the value itself. This is wrong considering the amount of people that hand edit the .config file. By the way - I have never understood the purpose of the flags (S_DEF_USER etc.) Can we have a few comments added to their definition? It allows to hold multiple configs, a user of it is conf_split_config() which loads another config and compares to the current config and updates the files under include/config as needed. It could also be used by front ends to display what actually changed compared to e.g. the saved config. Took a deeper look. So we can have 4 different set of vlaues where the value indexed by S_DEF_USER is the one that is actually used and the other three can be used to hold values. I will try to document this in expr.h Patch will be sent to you for review. One of the blockers are that kconfig does not support more than one prompt for a choice symbol. Is this something you can fix - or sketch how to fix it? The basic idea is to add a name to the choice, so multiple choices can be grouped together. This requires some changes to the dependency check to make sure one choice option doesn't depend on another (which is currently enforced by the syntax). Do you have any suggestions how to properly fix this? Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Thu, 15 Nov 2007, Sam Ravnborg wrote: The value can be supplied on the command-line so we need to validate input. Is there a need for this? Yes. We would like to set 64BIT or not in other than x86 cases. And way forward was not to override ARCH as in the x86 case. Can we please can get some consistency in this? We have a .config file for a reason, what's wrong with using it? Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Why can't this be fixed properly now? You don't even need this patch, just use ARCH to set 64BIT in the Kconfig as I've shown. These are two different uses, when reading a .config only the basic syntax is checked, but not the value itself. This is wrong considering the amount of people that hand edit the .config file. It's not, the actual symbol value is set later depending on the dependency constraints. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman. The value can be supplied on the command-line so we need to validate input. Is there a need for this? Yes. We would like to set 64BIT or not in other than x86 cases. And way forward was not to override ARCH as in the x86 case. Can we please can get some consistency in this? We have a .config file for a reason, what's wrong with using it? We need to set a selected few values in a few cases where we do not have a .config file. allmodconfig for x86 for instance. We would like to generate a 32-bit and a 64-bit version. Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Why can't this be fixed properly now? You don't even need this patch, just use ARCH to set 64BIT in the Kconfig as I've shown. Because the patch is in mainline and has been tested by a lot of people during the last week. And as the functionality is almost equal I do not see it as a big deal to have the less-perfect solution in one kernel release. And the only reason the patch were applied to mainline was to fix the build of the merged x86 architecute - otherwise it was in no way -rc material. These are two different uses, when reading a .config only the basic syntax is checked, but not the value itself. This is wrong considering the amount of people that hand edit the .config file. It's not, the actual symbol value is set later depending on the dependency constraints. My point is that the .config file is handedited so the syntax should be checked to best possible extent. If someone specify CONFIG_64BIT=64 we should error out. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On Thu, 15 Nov 2007, Sam Ravnborg wrote: Can we please can get some consistency in this? We have a .config file for a reason, what's wrong with using it? We need to set a selected few values in a few cases where we do not have a .config file. allmodconfig for x86 for instance. We would like to generate a 32-bit and a 64-bit version. This can already be set via all.config/allmod.config. Where is this need coming from? The point is that I don't like to add an interface, which is maybe used by two people, who should be perfectly capable using an existing superior mechanism. Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Why can't this be fixed properly now? You don't even need this patch, just use ARCH to set 64BIT in the Kconfig as I've shown. Because the patch is in mainline and has been tested by a lot of people during the last week. And as the functionality is almost equal I do not see it as a big deal to have the less-perfect solution in one kernel release. And the only reason the patch were applied to mainline was to fix the build of the merged x86 architecute - otherwise it was in no way -rc material. I showed you a solution, which requires no patch at all, while your patch adds extra functionality which is questionable. Why is a quick hack preferable over a proper solution? Either explain why my solution isn't usable or _please_ revert the K64BIT changes. These are two different uses, when reading a .config only the basic syntax is checked, but not the value itself. This is wrong considering the amount of people that hand edit the .config file. It's not, the actual symbol value is set later depending on the dependency constraints. My point is that the .config file is handedited so the syntax should be checked to best possible extent. If someone specify CONFIG_64BIT=64 we should error out. The other function doesn't complain about it either. There is already only limited error checking, e.g. there is no complaint that the value isn't really set (because it was selected by something else), otherwise the .config check during a kernel upgrades would be a lot noisier than it already is. Anyone directly editing .config should know what he is doing. bye, Roman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Thu, Nov 15, 2007 at 10:24:05PM +0100, Roman Zippel wrote: Hi, On Thu, 15 Nov 2007, Sam Ravnborg wrote: Can we please can get some consistency in this? We have a .config file for a reason, what's wrong with using it? We need to set a selected few values in a few cases where we do not have a .config file. allmodconfig for x86 for instance. We would like to generate a 32-bit and a 64-bit version. This can already be set via all.config/allmod.config. Where is this need coming from? The point is that I don't like to add an interface, which is maybe used by two people, who should be perfectly capable using an existing superior mechanism. When you say two people I am afraid we are not talking about the same case. Please revert the K64BIT changes and use this instead. I will finish up your patch and target it for next merge window. Why can't this be fixed properly now? You don't even need this patch, just use ARCH to set 64BIT in the Kconfig as I've shown. Because the patch is in mainline and has been tested by a lot of people during the last week. And as the functionality is almost equal I do not see it as a big deal to have the less-perfect solution in one kernel release. And the only reason the patch were applied to mainline was to fix the build of the merged x86 architecute - otherwise it was in no way -rc material. I showed you a solution, which requires no patch at all, while your patch adds extra functionality which is questionable. Why is a quick hack preferable over a proper solution? Either explain why my solution isn't usable or _please_ revert the K64BIT changes. You suggest just to check ARCH value and not apply your patch. This was not my initial understanding as was hopefully obvious from my reply. So you suggest to make the ARCH= setting on the command line mandatory again even for a configured kernel which is a step backward. I assume your patch also has this drawback - no? If user did NOT specify ARCH we should use the kernel configuration - which your solution fail to do. If user did specify ARCH and the kernel is configured then what? - Ignore the ARCH= setting - Warn if they do not match - Always adhere to the ARCH setting Accepting the solution where we check the ARCH as you suggested and loose the benefits of letting the configuration be the master should be OK for upcoming kernel release. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
You suggest just to check ARCH value and not apply your patch. This was
not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
If user did NOT specify ARCH we should use the kernel configuration - which
your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Makefile |3 ++-
arch/x86/Kconfig |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -3,8 +3,8 @@ mainmenu Linux Kernel Configuration for
# Select 32 or 64 bit
config 64BIT
- bool 64-bit kernel
- default n
+ bool 64-bit kernel if ARCH=x86
+ default ARCH=x86_64
help
Say yes to build a 64-bit kernel - formerly known as x86_64
Say no to build a 32-bit kernel - formerly known as i386Revert
9c900a9c9d9351e55ab6a84e12e3a52c474c7c8b
0f855aa64b3f63d35a891510cf7db932a435c116
2a113281f5cd2febbab21a93c8943f8d3eece4d3
and K64BIT parts of
daa93fab824f2b8c35bd11670c7fab2f32b2de5f
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Makefile|4 -
README |2
scripts/kconfig/conf.c |1
scripts/kconfig/confdata.c | 146
scripts/kconfig/lkc_proto.h |1
5 files changed, 56 insertions(+), 98 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -200,11 +200,9 @@ SRCARCH:= $(ARCH)
# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
SRCARCH := x86
-K64BIT := n
endif
ifeq ($(ARCH),x86_64)
SRCARCH := x86
-K64BIT := y
endif
KCONFIG_CONFIG ?= .config
@@ -341,7 +339,7 @@ KERNELRELEASE = $(shell cat include/conf
KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-export ARCH SRCARCH K64BIT CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD
CC
+export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
Index: linux-2.6/README
===
--- linux-2.6.orig/README
+++ linux-2.6/README
@@ -194,8 +194,6 @@ CONFIGURING the kernel:
make *config checks for a file named all{yes/mod/no/random}.config
for symbol values that are to be forced. If this file is not found,
it checks for a file named all.config to contain forced values.
- Finally it checks the environment variable K64BIT and if found, sets
- the config symbol 64BIT to the value of the K64BIT variable.
NOTES on make config:
- having unnecessary drivers will make the kernel bigger, and can
Index: linux-2.6/scripts/kconfig/conf.c
===
--- linux-2.6.orig/scripts/kconfig/conf.c
+++ linux-2.6/scripts/kconfig/conf.c
@@ -591,7 +591,6 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat(all.config, tmpstat))
conf_read_simple(all.config, S_DEF_USER);
- conf_set_env_sym(K64BIT, 64BIT, S_DEF_USER);
break;
default:
break;
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -83,95 +83,6 @@ char *conf_get_default_confname(void)
return name;
}
-static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char
*p)
-{
- char *p2;
-
- switch (sym-type) {
- case
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
You suggest just to check ARCH value and not apply your patch. This was
not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
If user did NOT specify ARCH we should use the kernel configuration - which
your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
Roman,
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam provided that
capability. Is that capability still present after this patch?
Thanks.
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Makefile |3 ++-
arch/x86/Kconfig |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -3,8 +3,8 @@ mainmenu Linux Kernel Configuration for
# Select 32 or 64 bit
config 64BIT
- bool 64-bit kernel
- default n
+ bool 64-bit kernel if ARCH=x86
+ default ARCH=x86_64
help
Say yes to build a 64-bit kernel - formerly known as x86_64
Say no to build a 32-bit kernel - formerly known as i386
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman.
If user did NOT specify ARCH we should use the kernel configuration - which
your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
Just eyeballing your patch I made following observations:
1) make all*config, randconfig, defconfig is broken on 64-bit boxes
2) A pure code refactoring patch is reverted for no obvious reason
3) Behavioral changes are not documented:
- 32-bit/64-bit can only be selected in config is you specify ARCH=x86
- ARCH= takes precedence over kernel config for a configured kernel
4) The changelogs miss title on reverted patches
All points are trivial to fix so I do not say your approach is
bad - just that the supplied patch is not good enough.
I will fix it up tonight and test it.
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman
On Wed, Nov 14, 2007 at 09:57:32PM +0100, Roman Zippel wrote:
> Hi,
>
> On Sat, 10 Nov 2007, Sam Ravnborg wrote:
>
> > + if (p) {
> > + char warning[100];
> > + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> > + conf_filename = warning;
> > + def_flags = SYMBOL_DEF << def;
> > + if (def == S_DEF_USER) {
> > + sym = sym_find(symname);
> > + if (!sym)
> > + return 1;
> > + } else {
> > + sym = sym_lookup(symname, 0);
> > + if (sym->type == S_UNKNOWN)
> > + sym->type = S_OTHER;
> > + }
> > + conf_set_sym_val(sym, def, def_flags, p);
> > + }
> > + return 0;
>
> This is more complex than necessary, this should be enough:
>
> sym = sym_find(symname);
> if (sym)
> sym_set_string_value(sym, p);
>
> This is not a direct user interface, so the potential stricter error
> checking is not really needed.
The value can be supplied on the command-line so we need to validate input.
The code is a copy of what happen when reading a all.config file and
the functionality should be equal.
Can we make that part simpler too?
By the way - I have never understood the purpose of the flags (S_DEF_USER etc.)
Can we have a few comments added to their definition?
> In general I think it's problematic that this is only checked, when the
> config system is called, i.e. with a configured kernel adding ARCH would
> have no effect, what makes this more confusing is that one can later omit
> the ARCH variable, since it's saved in the .config.
The future plan is to set the architecture as part of the configuration step
and not by ARCH=. The ARCH= notation will continue to be supported
but will merely be a hint about the desired architecture.
The only place where it will play a real effect is when generating
allnoconfig, allyesconfig, allmodconfig, randconfig.
Some consistency check will likely be added - but a pure 'make' will
build the kernel with the configured ARCH and the configured CROSS_COMPILE
setting.
One of the blockers are that kconfig does not support more than one prompt
for a choice symbol. Is this something you can fix - or sketch how to fix it?
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> + if (p) {
> + char warning[100];
> + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> + conf_filename = warning;
> + def_flags = SYMBOL_DEF << def;
> + if (def == S_DEF_USER) {
> + sym = sym_find(symname);
> + if (!sym)
> + return 1;
> + } else {
> + sym = sym_lookup(symname, 0);
> + if (sym->type == S_UNKNOWN)
> + sym->type = S_OTHER;
> + }
> + conf_set_sym_val(sym, def, def_flags, p);
> + }
> + return 0;
This is more complex than necessary, this should be enough:
sym = sym_find(symname);
if (sym)
sym_set_string_value(sym, p);
This is not a direct user interface, so the potential stricter error
checking is not really needed.
In general I think it's problematic that this is only checked, when the
config system is called, i.e. with a configured kernel adding ARCH would
have no effect, what makes this more confusing is that one can later omit
the ARCH variable, since it's saved in the .config. I think it would be
better to check for this directly in the Makefile and then use a separate
tool to set the variable directly (which could be simply sed or a simple
helper program).
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
+ if (p) {
+ char warning[100];
+ sprintf(warning, Environment variable (%s = \%s\), env, p);
+ conf_filename = warning;
+ def_flags = SYMBOL_DEF def;
+ if (def == S_DEF_USER) {
+ sym = sym_find(symname);
+ if (!sym)
+ return 1;
+ } else {
+ sym = sym_lookup(symname, 0);
+ if (sym-type == S_UNKNOWN)
+ sym-type = S_OTHER;
+ }
+ conf_set_sym_val(sym, def, def_flags, p);
+ }
+ return 0;
This is more complex than necessary, this should be enough:
sym = sym_find(symname);
if (sym)
sym_set_string_value(sym, p);
This is not a direct user interface, so the potential stricter error
checking is not really needed.
In general I think it's problematic that this is only checked, when the
config system is called, i.e. with a configured kernel adding ARCH would
have no effect, what makes this more confusing is that one can later omit
the ARCH variable, since it's saved in the .config. I think it would be
better to check for this directly in the Makefile and then use a separate
tool to set the variable directly (which could be simply sed or a simple
helper program).
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman
On Wed, Nov 14, 2007 at 09:57:32PM +0100, Roman Zippel wrote:
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
+ if (p) {
+ char warning[100];
+ sprintf(warning, Environment variable (%s = \%s\), env, p);
+ conf_filename = warning;
+ def_flags = SYMBOL_DEF def;
+ if (def == S_DEF_USER) {
+ sym = sym_find(symname);
+ if (!sym)
+ return 1;
+ } else {
+ sym = sym_lookup(symname, 0);
+ if (sym-type == S_UNKNOWN)
+ sym-type = S_OTHER;
+ }
+ conf_set_sym_val(sym, def, def_flags, p);
+ }
+ return 0;
This is more complex than necessary, this should be enough:
sym = sym_find(symname);
if (sym)
sym_set_string_value(sym, p);
This is not a direct user interface, so the potential stricter error
checking is not really needed.
The value can be supplied on the command-line so we need to validate input.
The code is a copy of what happen when reading a all.config file and
the functionality should be equal.
Can we make that part simpler too?
By the way - I have never understood the purpose of the flags (S_DEF_USER etc.)
Can we have a few comments added to their definition?
In general I think it's problematic that this is only checked, when the
config system is called, i.e. with a configured kernel adding ARCH would
have no effect, what makes this more confusing is that one can later omit
the ARCH variable, since it's saved in the .config.
The future plan is to set the architecture as part of the configuration step
and not by ARCH=. The ARCH= notation will continue to be supported
but will merely be a hint about the desired architecture.
The only place where it will play a real effect is when generating
allnoconfig, allyesconfig, allmodconfig, randconfig.
Some consistency check will likely be added - but a pure 'make' will
build the kernel with the configured ARCH and the configured CROSS_COMPILE
setting.
One of the blockers are that kconfig does not support more than one prompt
for a choice symbol. Is this something you can fix - or sketch how to fix it?
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > So it's not strictly an > > output directory, more a build directory. > The opposite > All output is placed there - including the configuration generated by > the *config frontends. I meant, it's not strictly an output directory as if I do make O=dir oldconfig it will _read_ dir/.config, so the O= directory is also used for input. And yes, I was splitting hairs ;-) Sorry for the confusion. -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 03:59:54PM +0100, Guillaume Chazarain wrote: > > I'm wondering why you don't use two different O= output directories > > instead? > > > > Depending on the CONFIG_ option in question this might even greatly > > reduce your compile times. > > /me is filled with wonder at the discovery that .config is saved in the O= > directory. Thanks a lot Adrian for this time saver. So it's not strictly an > output directory, more a build directory. The opposite All output is placed there - including the configuration generated by the *config frontends. It is not limited to kernel-build output. One of the use cases for "make O=.." is a setup where the kernel source is located in a RO location (CDROM, restricted permissions etc). Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > Another important point is that users that know about and see CONFIG_* > variables are kernel hackers, not the normal kconfig users. But kconfig is mainly for kernel hackers, otherwise it would be called CML2 ;-) > > Also, when working on a specific feature of the kernel, I tend to > > install both a kernel with the CONFIG_ option set and one with > > the option unset. Scripts to do that can twiddle the .config file, > > but it would be more convenient if kbuild could avoid that. > > I'm wondering why you don't use two different O= output directories > instead? > > Depending on the CONFIG_ option in question this might even greatly > reduce your compile times. /me is filled with wonder at the discovery that .config is saved in the O= directory. Thanks a lot Adrian for this time saver. So it's not strictly an output directory, more a build directory. I still think "make oldconfig CONFIG_FOO=bar" is useful for the occasional config change, but thanks again for this great tip. -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 01:43:28PM +0100, Guillaume Chazarain wrote: > Hi Adrian, Hi Guillaume, > On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > What exactly are the use cases where someone would need this? > > Glad you asked. Today, when I want to recompile a kernel while > changing a CONFIG_ option, I manually edit the .config, > remove the appropriate line and then run make oldconfig. > I'd like to be able to do: make oldconfig CONFIG_FOO=bar. first of all it's obvious that there can't be any guarantee that your CONFIG_FOO variable will actually get the value bar since dependencies might enable or disable it despite you wanting the opposite. Another important point is that users that know about and see CONFIG_* variables are kernel hackers, not the normal kconfig users. > Also, when working on a specific feature of the kernel, I tend to > install both a kernel with the CONFIG_ option set and one with > the option unset. Scripts to do that can twiddle the .config file, > but it would be more convenient if kbuild could avoid that. I'm wondering why you don't use two different O= output directories instead? Depending on the CONFIG_ option in question this might even greatly reduce your compile times. And you won't upgrade the kernel you work against that often compared to working on and testing of your own changes when developing code. > As you see, I'm more interested in make oldconfig than > make all*config. That's clear. > Cheers. > Guillaume cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Adrian, On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > What exactly are the use cases where someone would need this? Glad you asked. Today, when I want to recompile a kernel while changing a CONFIG_ option, I manually edit the .config, remove the appropriate line and then run make oldconfig. I'd like to be able to do: make oldconfig CONFIG_FOO=bar. Also, when working on a specific feature of the kernel, I tend to install both a kernel with the CONFIG_ option set and one with the option unset. Scripts to do that can twiddle the .config file, but it would be more convenient if kbuild could avoid that. As you see, I'm more interested in make oldconfig than make all*config. Cheers. -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Adrian, On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote: What exactly are the use cases where someone would need this? Glad you asked. Today, when I want to recompile a kernel while changing a CONFIG_ option, I manually edit the .config, remove the appropriate line and then run make oldconfig. I'd like to be able to do: make oldconfig CONFIG_FOO=bar. Also, when working on a specific feature of the kernel, I tend to install both a kernel with the CONFIG_ option set and one with the option unset. Scripts to do that can twiddle the .config file, but it would be more convenient if kbuild could avoid that. As you see, I'm more interested in make oldconfig than make all*config. Cheers. -- Guillaume - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 01:43:28PM +0100, Guillaume Chazarain wrote: Hi Adrian, Hi Guillaume, On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote: What exactly are the use cases where someone would need this? Glad you asked. Today, when I want to recompile a kernel while changing a CONFIG_ option, I manually edit the .config, remove the appropriate line and then run make oldconfig. I'd like to be able to do: make oldconfig CONFIG_FOO=bar. first of all it's obvious that there can't be any guarantee that your CONFIG_FOO variable will actually get the value bar since dependencies might enable or disable it despite you wanting the opposite. Another important point is that users that know about and see CONFIG_* variables are kernel hackers, not the normal kconfig users. Also, when working on a specific feature of the kernel, I tend to install both a kernel with the CONFIG_ option set and one with the option unset. Scripts to do that can twiddle the .config file, but it would be more convenient if kbuild could avoid that. I'm wondering why you don't use two different O= output directories instead? Depending on the CONFIG_ option in question this might even greatly reduce your compile times. And you won't upgrade the kernel you work against that often compared to working on and testing of your own changes when developing code. As you see, I'm more interested in make oldconfig than make all*config. That's clear. Cheers. Guillaume cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote: Another important point is that users that know about and see CONFIG_* variables are kernel hackers, not the normal kconfig users. But kconfig is mainly for kernel hackers, otherwise it would be called CML2 ;-) Also, when working on a specific feature of the kernel, I tend to install both a kernel with the CONFIG_ option set and one with the option unset. Scripts to do that can twiddle the .config file, but it would be more convenient if kbuild could avoid that. I'm wondering why you don't use two different O= output directories instead? Depending on the CONFIG_ option in question this might even greatly reduce your compile times. /me is filled with wonder at the discovery that .config is saved in the O= directory. Thanks a lot Adrian for this time saver. So it's not strictly an output directory, more a build directory. I still think make oldconfig CONFIG_FOO=bar is useful for the occasional config change, but thanks again for this great tip. -- Guillaume - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sun, Nov 11, 2007 at 03:59:54PM +0100, Guillaume Chazarain wrote: I'm wondering why you don't use two different O= output directories instead? Depending on the CONFIG_ option in question this might even greatly reduce your compile times. /me is filled with wonder at the discovery that .config is saved in the O= directory. Thanks a lot Adrian for this time saver. So it's not strictly an output directory, more a build directory. The opposite All output is placed there - including the configuration generated by the *config frontends. It is not limited to kernel-build output. One of the use cases for make O=.. is a setup where the kernel source is located in a RO location (CDROM, restricted permissions etc). Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On 11/11/07, Sam Ravnborg [EMAIL PROTECTED] wrote: So it's not strictly an output directory, more a build directory. The opposite All output is placed there - including the configuration generated by the *config frontends. I meant, it's not strictly an output directory as if I do make O=dir oldconfig it will _read_ dir/.config, so the O= directory is also used for input. And yes, I was splitting hairs ;-) Sorry for the confusion. -- Guillaume - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, Nov 10, 2007 at 09:55:06PM +0100, Guillaume Chazarain wrote: > Hi, > > On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > The variable K64BIT can now be used to select the > > value of CONFIG_64BIT. > > Why not calling the environment variable CONFIG_64BIT, > in preparation of the day when all CONFIG_ variables can > be passed by environment variables? What exactly are the use cases where someone would need this? > Guillaume cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, Nov 10, 2007 at 02:16:19PM -0800, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
>
> > The variable K64BIT can now be used to select the
> > value of CONFIG_64BIT.
> >
> > This is for example useful for powerpc to generate
> > allmodconfig for both bit sizes - like this:
> > make ARCH=powerpc K64BIT=y
> > make ARCH=powerpc K64BIT=n
> >
> > To use this the Kconfig file must use "64BIT" as the
> > config value to select between 32 and 64 bit.
> >
> > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> > ---
> > scripts/kconfig/conf.c |1 +
> > scripts/kconfig/confdata.c | 27 +++
> > scripts/kconfig/lkc_proto.h |1 +
> > 3 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> > index a38787a..c6bee85 100644
> > --- a/scripts/kconfig/conf.c
> > +++ b/scripts/kconfig/conf.c
> > @@ -591,6 +591,7 @@ int main(int ac, char **av)
> > conf_read_simple(name, S_DEF_USER);
> > else if (!stat("all.config", ))
> > conf_read_simple("all.config", S_DEF_USER);
> > + conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
> > break;
> > default:
> > break;
> > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> > index e0f402f..0cb7555 100644
> > --- a/scripts/kconfig/confdata.c
> > +++ b/scripts/kconfig/confdata.c
> > @@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int
> > def, int def_flags, char *p)
> > return 0;
> > }
> >
> > +/* Read an environment variable and assign the vaule to the symbol */
>
> value
>
> > +int conf_set_env_sym(const char *env, const char *symname, int def)
> > +{
> > + struct symbol *sym;
> > + char *p;
> > + int def_flags;
> > +
> > + p = getenv(env);
> > + if (p) {
> > + char warning[100];
> > + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> > + conf_filename = warning;
>
> What's with and here? I don't see how
> they are used in this function or in the caller of this function.
Added to allow conf_warning to print out something usefull.
Like in the following example:
make K64BIT=randy allnoconfig
Environment variable (K64BIT = "randy"):0:warning: symbol value 'randy' invalid
for 64BIT
This could look better - but I preferred this version for the
less readable:
(null):0:warning: symbol value 'randy' invalid for 64BIT
Thanks for the other inputs. I am correcting them in
my local patch-set. Before resubmit I willawait further comments.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
>
> This is for example useful for powerpc to generate
> allmodconfig for both bit sizes - like this:
> make ARCH=powerpc K64BIT=y
> make ARCH=powerpc K64BIT=n
>
> To use this the Kconfig file must use "64BIT" as the
> config value to select between 32 and 64 bit.
>
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> ---
> scripts/kconfig/conf.c |1 +
> scripts/kconfig/confdata.c | 27 +++
> scripts/kconfig/lkc_proto.h |1 +
> 3 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index a38787a..c6bee85 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -591,6 +591,7 @@ int main(int ac, char **av)
> conf_read_simple(name, S_DEF_USER);
> else if (!stat("all.config", ))
> conf_read_simple("all.config", S_DEF_USER);
> + conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
> break;
> default:
> break;
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index e0f402f..0cb7555 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int def,
> int def_flags, char *p)
> return 0;
> }
>
> +/* Read an environment variable and assign the vaule to the symbol */
value
> +int conf_set_env_sym(const char *env, const char *symname, int def)
> +{
> + struct symbol *sym;
> + char *p;
> + int def_flags;
> +
> + p = getenv(env);
> + if (p) {
> + char warning[100];
> + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> + conf_filename = warning;
What's with and here? I don't see how
they are used in this function or in the caller of this function.
> + def_flags = SYMBOL_DEF << def;
> + if (def == S_DEF_USER) {
> + sym = sym_find(symname);
> + if (!sym)
> + return 1;
> + } else {
> + sym = sym_lookup(symname, 0);
> + if (sym->type == S_UNKNOWN)
> + sym->type = S_OTHER;
> + }
> + conf_set_sym_val(sym, def, def_flags, p);
> + }
> + return 0;
> +}
> +
> int conf_read_simple(const char *name, int def)
> {
> FILE *in = NULL;
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > The variable K64BIT can now be used to select the > value of CONFIG_64BIT. Why not calling the environment variable CONFIG_64BIT, in preparation of the day when all CONFIG_ variables can be passed by environment variables? -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi, On 11/10/07, Sam Ravnborg [EMAIL PROTECTED] wrote: The variable K64BIT can now be used to select the value of CONFIG_64BIT. Why not calling the environment variable CONFIG_64BIT, in preparation of the day when all CONFIG_ variables can be passed by environment variables? -- Guillaume - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
This is for example useful for powerpc to generate
allmodconfig for both bit sizes - like this:
make ARCH=powerpc K64BIT=y
make ARCH=powerpc K64BIT=n
To use this the Kconfig file must use 64BIT as the
config value to select between 32 and 64 bit.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
scripts/kconfig/conf.c |1 +
scripts/kconfig/confdata.c | 27 +++
scripts/kconfig/lkc_proto.h |1 +
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index a38787a..c6bee85 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -591,6 +591,7 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat(all.config, tmpstat))
conf_read_simple(all.config, S_DEF_USER);
+ conf_set_env_sym(K64BIT, 64BIT, S_DEF_USER);
break;
default:
break;
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..0cb7555 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int def,
int def_flags, char *p)
return 0;
}
+/* Read an environment variable and assign the vaule to the symbol */
value
+int conf_set_env_sym(const char *env, const char *symname, int def)
+{
+ struct symbol *sym;
+ char *p;
+ int def_flags;
+
+ p = getenv(env);
+ if (p) {
+ char warning[100];
+ sprintf(warning, Environment variable (%s = \%s\), env, p);
+ conf_filename = warning;
What's with warning and conf_filename here? I don't see how
they are used in this function or in the caller of this function.
+ def_flags = SYMBOL_DEF def;
+ if (def == S_DEF_USER) {
+ sym = sym_find(symname);
+ if (!sym)
+ return 1;
+ } else {
+ sym = sym_lookup(symname, 0);
+ if (sym-type == S_UNKNOWN)
+ sym-type = S_OTHER;
+ }
+ conf_set_sym_val(sym, def, def_flags, p);
+ }
+ return 0;
+}
+
int conf_read_simple(const char *name, int def)
{
FILE *in = NULL;
---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, Nov 10, 2007 at 02:16:19PM -0800, Randy Dunlap wrote:
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
This is for example useful for powerpc to generate
allmodconfig for both bit sizes - like this:
make ARCH=powerpc K64BIT=y
make ARCH=powerpc K64BIT=n
To use this the Kconfig file must use 64BIT as the
config value to select between 32 and 64 bit.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
scripts/kconfig/conf.c |1 +
scripts/kconfig/confdata.c | 27 +++
scripts/kconfig/lkc_proto.h |1 +
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index a38787a..c6bee85 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -591,6 +591,7 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat(all.config, tmpstat))
conf_read_simple(all.config, S_DEF_USER);
+ conf_set_env_sym(K64BIT, 64BIT, S_DEF_USER);
break;
default:
break;
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..0cb7555 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int
def, int def_flags, char *p)
return 0;
}
+/* Read an environment variable and assign the vaule to the symbol */
value
+int conf_set_env_sym(const char *env, const char *symname, int def)
+{
+ struct symbol *sym;
+ char *p;
+ int def_flags;
+
+ p = getenv(env);
+ if (p) {
+ char warning[100];
+ sprintf(warning, Environment variable (%s = \%s\), env, p);
+ conf_filename = warning;
What's with warning and conf_filename here? I don't see how
they are used in this function or in the caller of this function.
Added to allow conf_warning to print out something usefull.
Like in the following example:
make K64BIT=randy allnoconfig
Environment variable (K64BIT = randy):0:warning: symbol value 'randy' invalid
for 64BIT
This could look better - but I preferred this version for the
less readable:
(null):0:warning: symbol value 'randy' invalid for 64BIT
Thanks for the other inputs. I am correcting them in
my local patch-set. Before resubmit I willawait further comments.
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Sat, Nov 10, 2007 at 09:55:06PM +0100, Guillaume Chazarain wrote: Hi, On 11/10/07, Sam Ravnborg [EMAIL PROTECTED] wrote: The variable K64BIT can now be used to select the value of CONFIG_64BIT. Why not calling the environment variable CONFIG_64BIT, in preparation of the day when all CONFIG_ variables can be passed by environment variables? What exactly are the use cases where someone would need this? Guillaume cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
