Messages in this thread | | | Date | Thu, 15 Nov 2007 21:45:20 +0100 | From | Sam Ravnborg <> | Subject | 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 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/
| |