Recently someone told me he had a bug on x86 and to reproduce
it I should "'make allyesconfig' and disable CONFIG_HOTPLUG=y".
But I didn't see it.
"make allyesconfig" is ambiguous on x86 and he had a 64bit computer.
There go another two hours compile time.
It makes sense to have the Kconfig default and the defconfig based on
whether you are on a 32bit or a 64bit machine, but it's complete
nonsense to not offer the Kconfig variable unless you had explicitely
given ARCH=x86 (in which case you could as well immediately set the ARCH
to i386 or x86_64).
Signed-off-by: Adrian Bunk <[email protected]>
---
This patch has been sent on:
- 17 Jan 2008
fcf848366a166812fa32b2a22f2631fcd4982cb4
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 80b7ba4..0e6e74d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3,7 +3,7 @@ mainmenu "Linux Kernel Configuration for x86"
# Select 32 or 64 bit
config 64BIT
- bool "64-bit kernel" if ARCH = "x86"
+ bool "64-bit kernel"
default ARCH = "x86_64"
help
Say yes to build a 64-bit kernel - formerly known as x86_64
* Adrian Bunk <[email protected]> wrote:
> # Select 32 or 64 bit
> config 64BIT
> - bool "64-bit kernel" if ARCH = "x86"
> + bool "64-bit kernel"
> default ARCH = "x86_64"
NACK. You have just broken:
make ARCH=i386 randconfig
on a 64-bit box that has a 32-bit .config in its kernel directory.
The randconfig/allyesconfig/allnoconfig variants override whatever is in
the current .config. Making the result depend on whatever is in the
.config at the moment is fundamentally wrong.
"oldconfig" on the other hand has correct sensitivity to the existing
.config - and that always worked correctly. So if you pop a 32-bit or a
64-bit .config into a kernel tree, that will be listened to, no matter
whether you are on a 32-bit or on a 64-bit host.
Ingo
On Fri, Feb 01, 2008 at 04:22:27PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[email protected]> wrote:
>
> > # Select 32 or 64 bit
> > config 64BIT
> > - bool "64-bit kernel" if ARCH = "x86"
> > + bool "64-bit kernel"
> > default ARCH = "x86_64"
>
> NACK. You have just broken:
>
> make ARCH=i386 randconfig
>
> on a 64-bit box that has a 32-bit .config in its kernel directory.
>
> The randconfig/allyesconfig/allnoconfig variants override whatever is in
> the current .config. Making the result depend on whatever is in the
> .config at the moment is fundamentally wrong.
>
> "oldconfig" on the other hand has correct sensitivity to the existing
> .config - and that always worked correctly. So if you pop a 32-bit or a
> 64-bit .config into a kernel tree, that will be listened to, no matter
> whether you are on a 32-bit or on a 64-bit host.
Do you have ARCH=x86 set in your environment, the command line or
patched into your Makefile when this works for you?
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
* Adrian Bunk <[email protected]> wrote:
> > make ARCH=i386 randconfig
> >
> > on a 64-bit box that has a 32-bit .config in its kernel directory.
> >
> > The randconfig/allyesconfig/allnoconfig variants override whatever
> > is in the current .config. Making the result depend on whatever is
> > in the .config at the moment is fundamentally wrong.
> >
> > "oldconfig" on the other hand has correct sensitivity to the
> > existing .config - and that always worked correctly. So if you pop a
> > 32-bit or a 64-bit .config into a kernel tree, that will be listened
> > to, no matter whether you are on a 32-bit or on a 64-bit host.
>
> Do you have ARCH=x86 set in your environment, the command line or
> patched into your Makefile when this works for you?
nope, it happens with vanilla and no ARCH environment variable set that
i know of. So you cannot see this behavior?
Ingo
On Mon, Feb 11, 2008 at 05:37:40PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[email protected]> wrote:
>
> > > make ARCH=i386 randconfig
> > >
> > > on a 64-bit box that has a 32-bit .config in its kernel directory.
> > >
> > > The randconfig/allyesconfig/allnoconfig variants override whatever
> > > is in the current .config. Making the result depend on whatever is
> > > in the .config at the moment is fundamentally wrong.
> > >
> > > "oldconfig" on the other hand has correct sensitivity to the
> > > existing .config - and that always worked correctly. So if you pop a
> > > 32-bit or a 64-bit .config into a kernel tree, that will be listened
> > > to, no matter whether you are on a 32-bit or on a 64-bit host.
> >
> > Do you have ARCH=x86 set in your environment, the command line or
> > patched into your Makefile when this works for you?
>
> nope, it happens with vanilla and no ARCH environment variable set that
> i know of. So you cannot see this behavior?
No.
In my experience there is no way for me to enable 64BIT without somehow
manually fiddling with ARCH.
No matter whether it's menuconfig or oldconfig or whatever else.
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> In my experience there is no way for me to enable 64BIT without somehow
> manually fiddling with ARCH.
>
> No matter whether it's menuconfig or oldconfig or whatever else.
>From the patch description when ARCH=x86 were introduced:
# make {allno,allyes,allmod,rand}config [ARCH=...]
option \ host arch | 32bit | 64bit
=====================================================
./. | 32bit | 64bit
ARCH=x86 | 32bit | 32bit
ARCH=i386 | 32bit | 32bit
ARCH=x86_64 | 64bit | 64bit
The general rule are that ARCH= and native architecture
takes precedence over the configuration.
So make ARCH=i386 [whatever] will always build a 32-bit
kernel no matter what the configuration says.
The configuration will be updated to 32-bit if it was
configured to 64-bit and the other way around.
This behaviour is consistent with previous behaviour so
no suprises here.
make ARCH=x86 will per default result in a 32-bit kernel
but as the only ARCH= value x86 allow the user to select
between 32-bit and 64-bit using menuconfig.
So what you see is what was then discussed and considered
optimal functionality.
We shall keep in mind the main target here is to keep
peoples systems running as usual when they shift to
the unified {32 bit / 64 bit} x86 arch.
If you want anything changed then do this with respect to
the intended behaviour as documented above and keep the
setup used by our less kernel skilled testers in mind.
And you do not belong to the "less kernel skilled"
testers base.
Sam
On Mon, Feb 11, 2008 at 06:13:21PM +0100, Sam Ravnborg wrote:
> > In my experience there is no way for me to enable 64BIT without somehow
> > manually fiddling with ARCH.
> >
> > No matter whether it's menuconfig or oldconfig or whatever else.
>
> >From the patch description when ARCH=x86 were introduced:
>
> # make {allno,allyes,allmod,rand}config [ARCH=...]
> option \ host arch | 32bit | 64bit
> =====================================================
> ./. | 32bit | 64bit
> ARCH=x86 | 32bit | 32bit
> ARCH=i386 | 32bit | 32bit
> ARCH=x86_64 | 64bit | 64bit
>
> The general rule are that ARCH= and native architecture
> takes precedence over the configuration.
> So make ARCH=i386 [whatever] will always build a 32-bit
> kernel no matter what the configuration says.
> The configuration will be updated to 32-bit if it was
> configured to 64-bit and the other way around.
>
> This behaviour is consistent with previous behaviour so
> no suprises here.
>
> make ARCH=x86 will per default result in a 32-bit kernel
> but as the only ARCH= value x86 allow the user to select
> between 32-bit and 64-bit using menuconfig.
>
> So what you see is what was then discussed and considered
> optimal functionality.
What you describe differs vastly from what Ingo considers optimal and
describes as seeing on his computer. Why does oldconfig preserve the
32/64bit for him?
And the fact that kconfig does not let you choose the 32/64bit unless
you explicitely set ARCH=x86 is for users simply confusing.
> We shall keep in mind the main target here is to keep
> peoples systems running as usual when they shift to
> the unified {32 bit / 64 bit} x86 arch.
>
> If you want anything changed then do this with respect to
> the intended behaviour as documented above and keep the
> setup used by our less kernel skilled testers in mind.
>
> And you do not belong to the "less kernel skilled"
> testers base.
Your table talks about {allno,allyes,allmod,rand}config, and this is
definitely not stuff "less kernel skilled testers" should be using.
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed