Messages in this thread | | | Date | Thu, 15 Nov 2007 20:25:55 +0100 | From | Sam Ravnborg <> | Subject | 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |