| Message ID | 1311986969.20983.52.camel@i7.infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: > I *frequently* waste a bunch of time when I take a 32-bit .config from a > test machine and try to build it on a faster 64-bit system, and its > existing setting of CONFIG_64BIT=n gets *changed* to match the build host. > Should we not try to fix this rather than introduce a new interface ? From my point of view, we (ie. Kbuild) should be intelligent enough to take the default from the .config, if one is present in the object directory, rather than trying to impose it's own view on what the ARCH should be. Is there case where we would have a .config, but would not use its content ? Thanks, - Arnaud > This is because the default setting for $ARCH when discovered from > 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), > which effectively force the setting of CONFIG_64BIT to match. We should > default to ARCH=x86 instead, finally completing the merge that we > started so long ago. > > This patch preserves the behaviour of the legacy ARCH settings for commands > such as: > > make ARCH=x86_64 randconfig > make ARCH=i386 randconfig > > ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those > would be better expressed as: > > make CONFIG_64BIT=y randconfig > make CONFIG_64BIT=n randconfig > > ... since that is a more generic way to set *any* config option, and > there's no other technical reason to keep the legacy ARCH values around > any more just to achieve that purpose; they could be removed at any > time. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org > --- > v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for > CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to > be explicitly turned off or 'make i386_defconfig' will give you 64-bit. > v3: Same patch as before; just updated changelog. > > Makefile | 3 ++- > arch/x86/Kconfig | 2 +- > arch/x86/Makefile | 4 ++++ > arch/x86/configs/i386_defconfig | 1 + > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index d018956..303df9b 100644 > --- a/Makefile > +++ b/Makefile > @@ -165,7 +165,8 @@ export srctree objtree VPATH > # then ARCH is assigned, getting whatever value it gets normally, and > # SUBARCH is subsequently ignored. > > -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ > +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ > + -e s/sun4u/sparc64/ \ > -e s/arm.*/arm/ -e s/sa110/arm/ \ > -e s/s390x/s390/ -e s/parisc64/parisc/ \ > -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 153aa6f..9467fdd 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1,7 +1,7 @@ > # Select 32 or 64 bit > config 64BIT > bool "64-bit kernel" if ARCH = "x86" > - default ARCH = "x86_64" > + default ARCH != "i386" > ---help--- > Say yes to build a 64-bit kernel - formerly known as x86_64 > Say no to build a 32-bit kernel - formerly known as i386 > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index b02e509..94c2d8c 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -2,7 +2,11 @@ > > # select defconfig based on actual architecture > ifeq ($(ARCH),x86) > + ifeq ($(shell uname -m),x86_64) > + KBUILD_DEFCONFIG := x86_64_defconfig > + else > KBUILD_DEFCONFIG := i386_defconfig > + endif > else > KBUILD_DEFCONFIG := $(ARCH)_defconfig > endif > diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig > index 2bf18059f..5f96c1c 100644 > --- a/arch/x86/configs/i386_defconfig > +++ b/arch/x86/configs/i386_defconfig > @@ -1,3 +1,4 @@ > +# CONFIG_64BIT is not set > CONFIG_EXPERIMENTAL=y > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_SYSVIPC=y > -- > 1.7.6 > > > > -- > dwmw2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2011-07-29 at 21:26 -0400, Arnaud Lacombe wrote: > > Should we not try to fix this rather than introduce a new interface ? This patch *does* fix it, without needing the new interface that I presented in a separate patch. The two patches I sent are not strictly dependent on one another. > From my point of view, we (ie. Kbuild) should be intelligent enough to > take the default from the .config, if one is present in the object > directory, rather than trying to impose it's own view on what the ARCH > should be. > > Is there case where we would have a .config, but would not use its > content ? Heh, I think you've missed some of the history here. I originally, a year or two ago, posted a patch which took precisely the approach I think you're advocating. It basically made the ARCH=x86 behaviour apply in all cases. It was reverted because it made 'make randconfig' actually *random* — *even* for the setting of CONFIG_64BIT, *even* when ARCH=i386 or ARCH=x86_64. The fact that KCONFIG_ALLCONFIG allows you to override *all* config options and not just CONFIG_64BIT, and that using the legacy ARCH= settings wasn't really necessary, was evidently not sufficient. It apparently *had* to be possible to switch using the command line. So I did two things — I fixed this patch so that it doesn't break that legacy use case of 'make ARCH=i386' or 'make ARCH=x86_64' to force the value of CONFIG_64BIT on or off, and I also posted a separate patch which gives a more *sensible* way to force *any* config options on or off from the 'make' command line, since the world is apparently going to end if we can't do that. The two patches can be considered to be entirely independent.
Hi, On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: > I *frequently* waste a bunch of time when I take a 32-bit .config from a > test machine and try to build it on a faster 64-bit system, and its > existing setting of CONFIG_64BIT=n gets *changed* to match the build host. > > This is because the default setting for $ARCH when discovered from > 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), > which effectively force the setting of CONFIG_64BIT to match. We should > default to ARCH=x86 instead, finally completing the merge that we > started so long ago. > > This patch preserves the behaviour of the legacy ARCH settings for commands > such as: > > make ARCH=x86_64 randconfig > make ARCH=i386 randconfig > > ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those > would be better expressed as: > > make CONFIG_64BIT=y randconfig > make CONFIG_64BIT=n randconfig > > ... since that is a more generic way to set *any* config option, and > there's no other technical reason to keep the legacy ARCH values around > any more just to achieve that purpose; they could be removed at any > time. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org > --- > v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for > CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to > be explicitly turned off or 'make i386_defconfig' will give you 64-bit. > v3: Same patch as before; just updated changelog. > > Makefile | 3 ++- > arch/x86/Kconfig | 2 +- > arch/x86/Makefile | 4 ++++ > arch/x86/configs/i386_defconfig | 1 + > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index d018956..303df9b 100644 > --- a/Makefile > +++ b/Makefile > @@ -165,7 +165,8 @@ export srctree objtree VPATH > # then ARCH is assigned, getting whatever value it gets normally, and > # SUBARCH is subsequently ignored. > > -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ > +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ > + -e s/sun4u/sparc64/ \ > -e s/arm.*/arm/ -e s/sa110/arm/ \ > -e s/s390x/s390/ -e s/parisc64/parisc/ \ > -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ this is breaking ARCH=um. - Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 30 Jul 2011, Arnaud Lacombe wrote:
> this is breaking ARCH=um.
Breaking in what way? Is it just that ARCH=um is broken for SUBARCH=x86,
and needed to be updated anyway? And still works is you manually set
SUBARCH to one of the legacy values?
I'll try to reproduce and take a look later thuis evening.
Hi, On Sat, Jul 30, 2011 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sat, 30 Jul 2011, Arnaud Lacombe wrote: > >> this is breaking ARCH=um. > > Breaking in what way? from arch/um/Makefile: [...] include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH) with the following Makefile-$(SUBARCH) available: % ls arch/um/Makefile-* [...] arch/um/Makefile-i386 arch/um/Makefile-x86_64 > Is it just that ARCH=um is broken for SUBARCH=x86, > and needed to be updated anyway? > well, from my point of view, it do not need to be updated. Your patch corrupt SUBARCH's purpose, that is: # SUBARCH tells the usermode build what the underlying arch is. Changing it will start to be really intrusive... > And still works is you manually set > SUBARCH to one of the legacy values? > no. the toplev Makefile use a direct immediate assignment, not a conditional one. - Arnaud > I'll try to reproduce and take a look later thuis evening. > > -- > dwmw2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/30/2011 09:33 AM, Arnaud Lacombe wrote: >> > well, from my point of view, it do not need to be updated. Your patch > corrupt SUBARCH's purpose, that is: > > # SUBARCH tells the usermode build what the underlying arch is. > For klibc integration, we ran into this problem as well: the set of architectures for the kernel simply isn't the same set as the architectures for userspace. For the kernel, x86 is an architecture, for userspace the architectures are x86_64 or i386 and they are fundamentally different in many, many ways. The main problem with SUBARCH is that it is ill-defined in the general case if SUBARCH contains a user space or a kernel space architecture. In that sense I would much prefer it if was called, say, USERARCH and was always available. It could even be set by Kconfig (CONFIG_USERARCH?) -hpa
Hi, On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: > I *frequently* waste a bunch of time when I take a 32-bit .config from a > test machine and try to build it on a faster 64-bit system, and its > existing setting of CONFIG_64BIT=n gets *changed* to match the build host. > > This is because the default setting for $ARCH when discovered from > 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), > which effectively force the setting of CONFIG_64BIT to match. We should > default to ARCH=x86 instead, finally completing the merge that we > started so long ago. > > This patch preserves the behaviour of the legacy ARCH settings for commands > such as: > > make ARCH=x86_64 randconfig > make ARCH=i386 randconfig > > ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those > would be better expressed as: > > make CONFIG_64BIT=y randconfig > make CONFIG_64BIT=n randconfig > > ... since that is a more generic way to set *any* config option, and > there's no other technical reason to keep the legacy ARCH values around > any more just to achieve that purpose; they could be removed at any > time. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org > --- > v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for > CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to > be explicitly turned off or 'make i386_defconfig' will give you 64-bit. > v3: Same patch as before; just updated changelog. > > Makefile | 3 ++- > arch/x86/Kconfig | 2 +- > arch/x86/Makefile | 4 ++++ > arch/x86/configs/i386_defconfig | 1 + > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index d018956..303df9b 100644 > --- a/Makefile > +++ b/Makefile > @@ -165,7 +165,8 @@ export srctree objtree VPATH > # then ARCH is assigned, getting whatever value it gets normally, and > # SUBARCH is subsequently ignored. > > -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ > +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ > + -e s/sun4u/sparc64/ \ > -e s/arm.*/arm/ -e s/sa110/arm/ \ > -e s/s390x/s390/ -e s/parisc64/parisc/ \ > -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 153aa6f..9467fdd 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1,7 +1,7 @@ > # Select 32 or 64 bit > config 64BIT > bool "64-bit kernel" if ARCH = "x86" > - default ARCH = "x86_64" > + default ARCH != "i386" If I'm reading this correctly, does this mean that someone doing an 'allyesconfig' on an i386 machine will get a configuration for a 64bits kernel[0] ? With your logic, you would require the user to manually specify CONFIG_64BIT=n, which should be automatic on such a system... This logic seems broken to me. - Arnaud [0]: both ARCH and SUBARCH will be x86, so the conditional will translate to 'y' > ---help--- > Say yes to build a 64-bit kernel - formerly known as x86_64 > Say no to build a 32-bit kernel - formerly known as i386 > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index b02e509..94c2d8c 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -2,7 +2,11 @@ > > # select defconfig based on actual architecture > ifeq ($(ARCH),x86) > + ifeq ($(shell uname -m),x86_64) > + KBUILD_DEFCONFIG := x86_64_defconfig > + else > KBUILD_DEFCONFIG := i386_defconfig > + endif > else > KBUILD_DEFCONFIG := $(ARCH)_defconfig > endif > diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig > index 2bf18059f..5f96c1c 100644 > --- a/arch/x86/configs/i386_defconfig > +++ b/arch/x86/configs/i386_defconfig > @@ -1,3 +1,4 @@ > +# CONFIG_64BIT is not set > CONFIG_EXPERIMENTAL=y > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_SYSVIPC=y > -- > 1.7.6 > > > > -- > dwmw2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2011-07-31 at 01:18 -0400, Arnaud Lacombe wrote: > If I'm reading this correctly, does this mean that someone doing an > 'allyesconfig' on an i386 machine will get a configuration for a > 64bits kernel[0] ? With your logic, you would require the user to > manually specify CONFIG_64BIT=n, which should be automatic on such a > system... Yes, that is entirely correct, and intentional. If the user asks for 'all yes', then the user gets 'all yes'. We do not attempt some kind of half-baked Aunt Tillie mode where we guess certain settings from the build host. It's not as if people often use 'allyesconfig' to build kernels they're actually going to *run*.
Hi, On Sat, Jul 30, 2011 at 11:52 AM, Arnaud Lacombe <lacombar@gmail.com> wrote: > Hi, > > On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: >> I *frequently* waste a bunch of time when I take a 32-bit .config from a >> test machine and try to build it on a faster 64-bit system, and its >> existing setting of CONFIG_64BIT=n gets *changed* to match the build host. >> >> This is because the default setting for $ARCH when discovered from >> 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), >> which effectively force the setting of CONFIG_64BIT to match. We should >> default to ARCH=x86 instead, finally completing the merge that we >> started so long ago. >> >> This patch preserves the behaviour of the legacy ARCH settings for commands >> such as: >> >> make ARCH=x86_64 randconfig >> make ARCH=i386 randconfig >> >> ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those >> would be better expressed as: >> >> make CONFIG_64BIT=y randconfig >> make CONFIG_64BIT=n randconfig >> >> ... since that is a more generic way to set *any* config option, and >> there's no other technical reason to keep the legacy ARCH values around >> any more just to achieve that purpose; they could be removed at any >> time. >> >> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> >> Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org >> --- >> v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for >> CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to >> be explicitly turned off or 'make i386_defconfig' will give you 64-bit. >> v3: Same patch as before; just updated changelog. >> >> Makefile | 3 ++- >> arch/x86/Kconfig | 2 +- >> arch/x86/Makefile | 4 ++++ >> arch/x86/configs/i386_defconfig | 1 + >> 4 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index d018956..303df9b 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -165,7 +165,8 @@ export srctree objtree VPATH >> # then ARCH is assigned, getting whatever value it gets normally, and >> # SUBARCH is subsequently ignored. >> >> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ >> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ >> + -e s/sun4u/sparc64/ \ >> -e s/arm.*/arm/ -e s/sa110/arm/ \ >> -e s/s390x/s390/ -e s/parisc64/parisc/ \ >> -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ > this is breaking ARCH=um. > FWIW, you are still breaking `scripts/checkstack.pl', `scripts/tags.sh' (all UML related) and this change will lead users of ARCH=i386 to trigger the cross-compile mode of modpost introduced in 4ce6efed48d736e3384c39ff87bda723e1f8e041. - Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2011-07-31 at 15:40 -0400, Arnaud Lacombe wrote: > FWIW, you are still breaking `scripts/checkstack.pl', > `scripts/tags.sh' (all UML related) Can you explain the nature of the breakage? It's probably also easy to fix (or was already arguably broken), but it would be helpful if you'd point at what you think is wrong rather than making me guess. > and this change will lead users of ARCH=i386 to trigger the > cross-compile mode of modpost introduced in > 4ce6efed48d736e3384c39ff87bda723e1f8e041. That doesn't seem unreasonable. After all, if the .config values are no longer being forcibly overridden to match the build host, you no longer *need* to add ARCH=i386 on the command line just to make the build system honour your existing configuration with CONFIG_64BIT=n. So there's absolutely no point in having ARCH=i386 there. If you want the more stringent checks, don't do that then. But I'll take a look at this too. Thanks for actually giving enough detail.
Hi, On Sun, Jul 31, 2011 at 4:00 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sun, 2011-07-31 at 15:40 -0400, Arnaud Lacombe wrote: >> FWIW, you are still breaking `scripts/checkstack.pl', >> `scripts/tags.sh' (all UML related) > > Can you explain the nature of the breakage? It's probably also easy to > fix (or was already arguably broken), but it would be helpful if you'd > point at what you think is wrong rather than making me guess. > scripts/tags.sh: [...] # Support um (which uses SUBARCH) if [ "${ARCH}" = "um" ]; then if [ "$SUBARCH" = "i386" ]; then archinclude=x86 elif [ "$SUBARCH" = "x86_64" ]; then archinclude=x86 else archinclude=${SUBARCH} fi fi So this one is not broken, but the conditionals are deadcode. I wonder if it should not just use ${SRCARCH}. Makefile: ifeq ($(ARCH), um) CHECKSTACK_ARCH := $(SUBARCH) else CHECKSTACK_ARCH := $(ARCH) endif checkstack: $(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \ $(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH) scripts/checkstack.pl: my (@stack, $re, $dre, $x, $xs); { my $arch = shift; if ($arch eq "") { $arch = `uname -m`; chomp($arch); } [...] } elsif ($arch eq 'x86_64') { # 2f60: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp $re = qr/^.*[as][du][db] \$(0x$x{1,8}),\%rsp$/o; $dre = qr/^.*[as][du][db] (\%.*),\%rsp$/o; this one actually is broken: % perl scripts/checkstack.pl x86 wrong or unknown architecture "x86" - Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: > I *frequently* waste a bunch of time when I take a 32-bit .config from a > test machine and try to build it on a faster 64-bit system, and its > existing setting of CONFIG_64BIT=n gets *changed* to match the build host. > > This is because the default setting for $ARCH when discovered from > 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), > which effectively force the setting of CONFIG_64BIT to match. We should > default to ARCH=x86 instead, finally completing the merge that we > started so long ago. > AFAICS, `scripts/mkcompile_h' ends up using ${ARCH} to build UTS_MACHINE, so it ends up being directly visible to userland. I would wonder which userland application (both script and binaries), relying on this interface, you are breaking... - Arnaud > This patch preserves the behaviour of the legacy ARCH settings for commands > such as: > > make ARCH=x86_64 randconfig > make ARCH=i386 randconfig > > ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those > would be better expressed as: > > make CONFIG_64BIT=y randconfig > make CONFIG_64BIT=n randconfig > > ... since that is a more generic way to set *any* config option, and > there's no other technical reason to keep the legacy ARCH values around > any more just to achieve that purpose; they could be removed at any > time. > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org > --- > v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for > CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to > be explicitly turned off or 'make i386_defconfig' will give you 64-bit. > v3: Same patch as before; just updated changelog. > > Makefile | 3 ++- > arch/x86/Kconfig | 2 +- > arch/x86/Makefile | 4 ++++ > arch/x86/configs/i386_defconfig | 1 + > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index d018956..303df9b 100644 > --- a/Makefile > +++ b/Makefile > @@ -165,7 +165,8 @@ export srctree objtree VPATH > # then ARCH is assigned, getting whatever value it gets normally, and > # SUBARCH is subsequently ignored. > > -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ > +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ > + -e s/sun4u/sparc64/ \ > -e s/arm.*/arm/ -e s/sa110/arm/ \ > -e s/s390x/s390/ -e s/parisc64/parisc/ \ > -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 153aa6f..9467fdd 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1,7 +1,7 @@ > # Select 32 or 64 bit > config 64BIT > bool "64-bit kernel" if ARCH = "x86" > - default ARCH = "x86_64" > + default ARCH != "i386" > ---help--- > Say yes to build a 64-bit kernel - formerly known as x86_64 > Say no to build a 32-bit kernel - formerly known as i386 > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index b02e509..94c2d8c 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -2,7 +2,11 @@ > > # select defconfig based on actual architecture > ifeq ($(ARCH),x86) > + ifeq ($(shell uname -m),x86_64) > + KBUILD_DEFCONFIG := x86_64_defconfig > + else > KBUILD_DEFCONFIG := i386_defconfig > + endif > else > KBUILD_DEFCONFIG := $(ARCH)_defconfig > endif > diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig > index 2bf18059f..5f96c1c 100644 > --- a/arch/x86/configs/i386_defconfig > +++ b/arch/x86/configs/i386_defconfig > @@ -1,3 +1,4 @@ > +# CONFIG_64BIT is not set > CONFIG_EXPERIMENTAL=y > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_SYSVIPC=y > -- > 1.7.6 > > > > -- > dwmw2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jul 31, 2011 at 5:47 PM, Arnaud Lacombe <lacombar@gmail.com> wrote: > Hi, > > On Fri, Jul 29, 2011 at 8:49 PM, David Woodhouse <dwmw2@infradead.org> wrote: >> I *frequently* waste a bunch of time when I take a 32-bit .config from a >> test machine and try to build it on a faster 64-bit system, and its >> existing setting of CONFIG_64BIT=n gets *changed* to match the build host. >> >> This is because the default setting for $ARCH when discovered from >> 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), >> which effectively force the setting of CONFIG_64BIT to match. We should >> default to ARCH=x86 instead, finally completing the merge that we >> started so long ago. >> > AFAICS, `scripts/mkcompile_h' ends up using ${ARCH} to build > UTS_MACHINE, so it ends up being directly visible to userland. I would > wonder which userland application (both script and binaries), relying > on this interface, you are breaking... > my bad, mkcompile_h uses an UTS_MACHINE variable defined by the arch/x86/Makefile. - Arnaud > - Arnaud > >> This patch preserves the behaviour of the legacy ARCH settings for commands >> such as: >> >> make ARCH=x86_64 randconfig >> make ARCH=i386 randconfig >> >> ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those >> would be better expressed as: >> >> make CONFIG_64BIT=y randconfig >> make CONFIG_64BIT=n randconfig >> >> ... since that is a more generic way to set *any* config option, and >> there's no other technical reason to keep the legacy ARCH values around >> any more just to achieve that purpose; they could be removed at any >> time. >> >> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> >> Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org >> --- >> v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for >> CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to >> be explicitly turned off or 'make i386_defconfig' will give you 64-bit. >> v3: Same patch as before; just updated changelog. >> >> Makefile | 3 ++- >> arch/x86/Kconfig | 2 +- >> arch/x86/Makefile | 4 ++++ >> arch/x86/configs/i386_defconfig | 1 + >> 4 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index d018956..303df9b 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -165,7 +165,8 @@ export srctree objtree VPATH >> # then ARCH is assigned, getting whatever value it gets normally, and >> # SUBARCH is subsequently ignored. >> >> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ >> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ >> + -e s/sun4u/sparc64/ \ >> -e s/arm.*/arm/ -e s/sa110/arm/ \ >> -e s/s390x/s390/ -e s/parisc64/parisc/ \ >> -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index 153aa6f..9467fdd 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -1,7 +1,7 @@ >> # Select 32 or 64 bit >> config 64BIT >> bool "64-bit kernel" if ARCH = "x86" >> - default ARCH = "x86_64" >> + default ARCH != "i386" >> ---help--- >> Say yes to build a 64-bit kernel - formerly known as x86_64 >> Say no to build a 32-bit kernel - formerly known as i386 >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile >> index b02e509..94c2d8c 100644 >> --- a/arch/x86/Makefile >> +++ b/arch/x86/Makefile >> @@ -2,7 +2,11 @@ >> >> # select defconfig based on actual architecture >> ifeq ($(ARCH),x86) >> + ifeq ($(shell uname -m),x86_64) >> + KBUILD_DEFCONFIG := x86_64_defconfig >> + else >> KBUILD_DEFCONFIG := i386_defconfig >> + endif >> else >> KBUILD_DEFCONFIG := $(ARCH)_defconfig >> endif >> diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig >> index 2bf18059f..5f96c1c 100644 >> --- a/arch/x86/configs/i386_defconfig >> +++ b/arch/x86/configs/i386_defconfig >> @@ -1,3 +1,4 @@ >> +# CONFIG_64BIT is not set >> CONFIG_EXPERIMENTAL=y >> # CONFIG_LOCALVERSION_AUTO is not set >> CONFIG_SYSVIPC=y >> -- >> 1.7.6 >> >> >> >> -- >> dwmw2 >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Makefile b/Makefile index d018956..303df9b 100644 --- a/Makefile +++ b/Makefile @@ -165,7 +165,8 @@ export srctree objtree VPATH # then ARCH is assigned, getting whatever value it gets normally, and # SUBARCH is subsequently ignored. -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ + -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ -e s/sa110/arm/ \ -e s/s390x/s390/ -e s/parisc64/parisc/ \ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 153aa6f..9467fdd 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1,7 +1,7 @@ # Select 32 or 64 bit config 64BIT bool "64-bit kernel" if ARCH = "x86" - default ARCH = "x86_64" + default ARCH != "i386" ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 diff --git a/arch/x86/Makefile b/arch/x86/Makefile index b02e509..94c2d8c 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -2,7 +2,11 @@ # select defconfig based on actual architecture ifeq ($(ARCH),x86) + ifeq ($(shell uname -m),x86_64) + KBUILD_DEFCONFIG := x86_64_defconfig + else KBUILD_DEFCONFIG := i386_defconfig + endif else KBUILD_DEFCONFIG := $(ARCH)_defconfig endif diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 2bf18059f..5f96c1c 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -1,3 +1,4 @@ +# CONFIG_64BIT is not set CONFIG_EXPERIMENTAL=y # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y
I *frequently* waste a bunch of time when I take a 32-bit .config from a test machine and try to build it on a faster 64-bit system, and its existing setting of CONFIG_64BIT=n gets *changed* to match the build host. This is because the default setting for $ARCH when discovered from 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), which effectively force the setting of CONFIG_64BIT to match. We should default to ARCH=x86 instead, finally completing the merge that we started so long ago. This patch preserves the behaviour of the legacy ARCH settings for commands such as: make ARCH=x86_64 randconfig make ARCH=i386 randconfig ... although since my commit "Enable 'make CONFIG_FOO=y oldconfig'" those would be better expressed as: make CONFIG_64BIT=y randconfig make CONFIG_64BIT=n randconfig ... since that is a more generic way to set *any* config option, and there's no other technical reason to keep the legacy ARCH values around any more just to achieve that purpose; they could be removed at any time. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org --- v2: Explicitly turn off CONFIG_64BIT in i386_defconfig. The default for CONFIG_64BIT has *changed* (from n to y) for ARCH=x86, so it needs to be explicitly turned off or 'make i386_defconfig' will give you 64-bit. v3: Same patch as before; just updated changelog. Makefile | 3 ++- arch/x86/Kconfig | 2 +- arch/x86/Makefile | 4 ++++ arch/x86/configs/i386_defconfig | 1 + 4 files changed, 8 insertions(+), 2 deletions(-)