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/