[lkml]   [2007]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-11-15 21:47    [W:0.081 / U:1.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site