[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0711152158310.1817@scrub.home>
Date: Thu, 15 Nov 2007 22:24:05 +0100 (CET)
From: Roman Zippel <zippel@...ux-m68k.org>
To: Sam Ravnborg <sam@...nborg.org>
cc: LKML <linux-kernel@...r.kernel.org>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists