* [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' @ 2011-05-29 22:14 David Woodhouse 2011-05-30 7:23 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-29 22:14 UTC (permalink / raw) To: x86, linux-kernel I wasted a bunch of time today because I'd taken a .config from my test machine and tried to build it, and the existing setting of CONFIG_X86_32 got corrupted. This patch fixes that. Last time I tried to fix this bug, I had to contend with Ingo's objection that he didn't actually want 'make randconfig' to give him a random config... so this is a variant of the patch which lets him use 'make ARCH=i386 randconfig' and 'make ARCH=x86_64 randconfig' to get not-entirely-random configurations. I still maintain that if you actually want a non-random 'randconfig', perhaps because you want it to be bootable on certain test machines, then you're going to need to hard-code a whole lot more than *one* config option — and you'd be better off coming up with a proper mechanism to do *that* instead of preserving the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack to achieve it only for the CONFIG_X86_32 option. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- Same patch as in https://patchwork.kernel.org/patch/33093/ diff --git a/Makefile b/Makefile index 123d858..7b3b7c5 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 cc6c53a..1f206b0 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 -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-29 22:14 [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' David Woodhouse @ 2011-05-30 7:23 ` Ingo Molnar 2011-05-30 8:57 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 7:23 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > I wasted a bunch of time today because I'd taken a .config from my > test machine and tried to build it, and the existing setting of > CONFIG_X86_32 got corrupted. > > This patch fixes that. Last time I tried to fix this bug, I had to > contend with Ingo's objection that he didn't actually want 'make > randconfig' to give him a random config... [...] You thoroughly misunderstood my prior regression report, the problem with your patch was that your patch actually *broke* existing filtered-randconfig behavior, for example trying to get a 64-bit randconfig: make ARCH=x86_64 randconfig ... will today produce a 64-bit randconfig while with your old change applied it produced a 32-bit randconfig 50% of the time. That randconfig behavior is an entirely expected and intuitive: if the ARCH=x86_64 condition is added to the command line then kconfig should not ignore it - why should randconfig override the user's wishes? Furthermore this behavior worked fine before your first patch so not only did your first patch make kconfig behavior less intuitive, it also caused a regression. Similarly, "make ARCH=i386 randconfig" will produce a 32-bit randconfig today, while with your old patch applied it produced a 64-bit randconfig 50% of the time. As i said it two years ago when you first submitted this patch: | I dont mind the change you are after, but randconfig should work as | expected too: if ARCH=x86_64 is passed it should generate a 64-bit | randconfig, not a 50% 32-bit one. I still don't mind "make oldconfig" picking up the bitness of the .config instead of the host system's (it is the more intuitive and more correct behavior) - although note that me not minding it is not enough: we still have to be on the lookout for people and tools relying on that behavior. So instead of complaining about my regression report i've updated the changelog as attached below - if you are fine with that then i'll commit and test it more widely. Thanks, Ingo --------------> Subject: x86, kconfig: Pick up the .config arch version in 'make oldconfig' From: David Woodhouse <dwmw2@infradead.org> Date: Sun, 29 May 2011 23:14:28 +0100 I wasted a bunch of time today because I'd taken a .config from my test machine and tried to build it, and the existing setting of CONFIG_X86_32 got changed to the host system's bitness which was 64-bit. This patch fixes that. Last time I tried to fix this bug, I had introduced a regression that broke: make ARCH=x86_64 randconfig make ARCH=i386 randconfig type of filtered-randconfig behavior which restricted randconfigs to 64-bit and 32-bit configs, respectively. This version fixes that so prior randconfig behavior is maintained. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org Signed-off-by: Ingo Molnar <mingo@elte.hu> --- Makefile | 3 ++- arch/x86/Kconfig | 2 +- arch/x86/Makefile | 4 ++++ 3 files changed, 7 insertions(+), 2 deletions(-) Index: linux/Makefile =================================================================== --- linux.orig/Makefile +++ linux/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/ \ Index: linux/arch/x86/Kconfig =================================================================== --- linux.orig/arch/x86/Kconfig +++ linux/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 Index: linux/arch/x86/Makefile =================================================================== --- linux.orig/arch/x86/Makefile +++ linux/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 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 7:23 ` Ingo Molnar @ 2011-05-30 8:57 ` David Woodhouse 2011-05-30 9:15 ` Ingo Molnar ` (2 more replies) 0 siblings, 3 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-30 8:57 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 2011-05-30 at 09:23 +0200, Ingo Molnar wrote: > You thoroughly misunderstood my prior regression report, the problem > with your patch was that your patch actually *broke* existing > filtered-randconfig behavior, for example trying to get a 64-bit > randconfig: > > make ARCH=x86_64 randconfig > > ... will today produce a 64-bit randconfig while with your old change > applied it produced a 32-bit randconfig 50% of the time. I believe that this 'filtered randconfig' behaviour is now fairly much the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. Other than that, we ought to finally be able to 'complete' the merge of 32-bit and 64-bit support into ARCH=x86, and remove the last traces of the obsolete ARCH={i386,x86_64} settings completely? Just as we did for 'ARCH=ppc{64,}' a few years ago. And as I said, it's still an incomplete solution if you actually want a 'filtered randconfig' to do anything *useful*. You'd be much better off implementing a *real* filtered randconfig that allows you to give a list of hard-coded options, rather than relying on a dirty hack that only actually sets *one* option of the many that you might need to 'hard-code' if you actually wanted a useful build. So no, I don't think I misunderstood your "regression report" at all. But go ahead and change the commit message if you must. As long as the bug gets fixed, I'm content. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 8:57 ` David Woodhouse @ 2011-05-30 9:15 ` Ingo Molnar 2011-05-30 9:27 ` David Woodhouse 2011-05-30 10:09 ` [PATCH v2] x86, kconfig: Pick up the .config arch version " David Woodhouse 2011-05-30 10:42 ` [PATCH] Fix corruption of CONFIG_X86_32 " Ingo Molnar 2011-05-30 11:05 ` Arnd Bergmann 2 siblings, 2 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 9:15 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 09:23 +0200, Ingo Molnar wrote: > > You thoroughly misunderstood my prior regression report, the problem > > with your patch was that your patch actually *broke* existing > > filtered-randconfig behavior, for example trying to get a 64-bit > > randconfig: > > > > make ARCH=x86_64 randconfig > > > > ... will today produce a 64-bit randconfig while with your old change > > applied it produced a 32-bit randconfig 50% of the time. > > I believe that this 'filtered randconfig' behaviour is now fairly much > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. I use "make ARCH=i386 defconfig" and "make ARCH=x86_64 defconfig" all the time. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 9:15 ` Ingo Molnar @ 2011-05-30 9:27 ` David Woodhouse 2011-05-30 9:53 ` Ingo Molnar 2011-05-30 10:40 ` Alexey Dobriyan 2011-05-30 10:09 ` [PATCH v2] x86, kconfig: Pick up the .config arch version " David Woodhouse 1 sibling, 2 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-30 9:27 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 2011-05-30 at 11:15 +0200, Ingo Molnar wrote: > > > I believe that this 'filtered randconfig' behaviour is now fairly much > > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. > > I use "make ARCH=i386 defconfig" and "make ARCH=x86_64 defconfig" all > the time. Good point. But shouldn't "make i386_defconfig" and "make x86_64_defconfig" do that? They *don't*, but I think that's just a bug: [dwmw2@i7 iommu-2.6]$ make V=1 i386_defconfig make -f scripts/Makefile.build obj=scripts/basic rm -f .tmp_quiet_recordmcount mkdir -p include/linux include/config make -f scripts/Makefile.build obj=scripts/kconfig i386_defconfig scripts/kconfig/conf --defconfig=arch/x86/configs/i386_defconfig Kconfig gr# # configuration written to .config # [dwmw2@i7 iommu-2.6]$ grep defconfig .config CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 9:27 ` David Woodhouse @ 2011-05-30 9:53 ` Ingo Molnar 2011-05-30 10:06 ` David Woodhouse 2011-05-30 10:40 ` Alexey Dobriyan 1 sibling, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 9:53 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 11:15 +0200, Ingo Molnar wrote: > > > > > I believe that this 'filtered randconfig' behaviour is now fairly much > > > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. > > > > I use "make ARCH=i386 defconfig" and "make ARCH=x86_64 defconfig" all > > the time. > > Good point. But shouldn't "make i386_defconfig" and "make > x86_64_defconfig" do that? Yeah, we could certainly fix (or extend?) kconfig to allow those forms too, if you would like to use them. I personally prefer 'make ARCH=i386 defconfig' and 'make ARCH=x86_64 defconfig' because it's a nice conceptual equivalent to: make ARCH=arm defconfig make ARCH=mips defconfig et al. 'make ARCH=x86 defconfig' should probably default to the host bitness version, or always default to 64-bit - right now it defaults to i386_defconfig. [ Note that some of the architectures are a bit weird there: for example 'make ARCH=powerpc' will only work if you use a PPC cross-compiler - but it generally works fine and i rely on that for cross-build tooling. ] As for your fix patch, is the wording i provided fine to you so i can commit it? I think we should treat it differently from any defconfig related fixes/enhancements and not delay it - the 2 years of delay was already too long IMHO! ;-) Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 9:53 ` Ingo Molnar @ 2011-05-30 10:06 ` David Woodhouse 2011-05-30 10:25 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 10:06 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 2011-05-30 at 11:53 +0200, Ingo Molnar wrote: > * David Woodhouse <dwmw2@infradead.org> wrote: > > Good point. But shouldn't "make i386_defconfig" and "make > > x86_64_defconfig" do that? > > Yeah, we could certainly fix (or extend?) kconfig to allow those > forms too, if you would like to use them. Those always worked. I actually *broke* it in my previous patch. Before that, the 'i386_defconfig' never actually needed to *specify* that it wanted CONFIG_64BIT=n, because that would never have been the default. Adding '# CONFIG_64BIT is not set' to arch/x86/configs/i386_defconfig fixes it. > I personally prefer 'make ARCH=i386 defconfig' and 'make ARCH=x86_64 > defconfig' because it's a nice conceptual equivalent to: > > make ARCH=arm defconfig > make ARCH=mips defconfig No, ARCH= is just for cross-compiling. If you're *on* an ARM or MIPS box, you don't need the ARCH= bit. And it *doesn't* follow the pattern you seem to be looking for, because it's *not* setting 32-bit or 64-bit compilation. ARM doesn't even *have* 64-bit support, but let's look at MIPS: If you want a 64-bit MIPS kernel, you do something like make bigsur_defconfig If you want a 32-bit MIPS kernel, you do something like make ar7_defconfig You *don't* set 'ARCH=mips32' or 'ARCH=mips64'; CONFIG_64BIT is just a config option. Of course, MIPS makes it more "interesting" because it doesn't do a "generic" kernel that boots on more than one machine. PowerPC is probably the better analogy. There, it's: make ppc_defconfig and make ppc64_defconfig And still no 'ARCH=ppc' or 'ARCH=ppc64'. Those got killed off a long time ago, when we merged the 32-bit and 64-bit code into arch/powerpc. And, as before, you don't need the ARCH=powerpc if you are already on a PowerPC box. That's just for cross-compilation. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:06 ` David Woodhouse @ 2011-05-30 10:25 ` Ingo Molnar 2011-05-30 11:01 ` David Woodhouse 2011-05-31 8:53 ` Geert Uytterhoeven 0 siblings, 2 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 10:25 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 11:53 +0200, Ingo Molnar wrote: > > * David Woodhouse <dwmw2@infradead.org> wrote: > > > Good point. But shouldn't "make i386_defconfig" and "make > > > x86_64_defconfig" do that? > > > > Yeah, we could certainly fix (or extend?) kconfig to allow those > > forms too, if you would like to use them. > > Those always worked. I actually *broke* it in my previous patch. [...] Oh, that needs fixing then. > [...] Before that, the 'i386_defconfig' never actually needed to > *specify* that it wanted CONFIG_64BIT=n, [...] Also arguably 'make i386_defconfig' has 'i386' implicit in its name, so from a human workflow logic POV it would be rather silly to require it. > [...] because that would never have been the default. Adding '# > CONFIG_64BIT is not set' to arch/x86/configs/i386_defconfig fixes > it. > > > I personally prefer 'make ARCH=i386 defconfig' and 'make ARCH=x86_64 > > defconfig' because it's a nice conceptual equivalent to: > > > > make ARCH=arm defconfig > > make ARCH=mips defconfig > > No, ARCH= is just for cross-compiling. If you're *on* an ARM or MIPS > box, you don't need the ARCH= bit. Still note that 'make ARCH=arm defconfig' will just work fine even without cross-building, so i often use just that if i want to see what default core kernel options ARM (or MIPS) has enabled these days. > And it *doesn't* follow the pattern you seem to be looking for, > because it's *not* setting 32-bit or 64-bit compilation. [...] Sure it is setting it implicitly: it is defaulting to some of the options, lacking any more specific input from the user. Just like 'ARCH=x86 defconfig' defaults to the i386_defconfig. > [...] ARM doesn't even *have* 64-bit support, but let's look at > MIPS: > > If you want a 64-bit MIPS kernel, you do something like > make bigsur_defconfig > > If you want a 32-bit MIPS kernel, you do something like > make ar7_defconfig And if i just want a MIPS defconfig i type 'make ARCH=mips defconfig' and get one. ARCH=i386 and ARCH=x86_64 are two legacy architecture abbreviations that are well established, so it makes quite a bit of sense to keep those in addition to ARCH=x86. They also happen to work rather intuitively both with defconfig and with randconfig. And note that while i already mentioned how 'randconfig' and 'defconfig' works with ARCH=i386 and ARCH=x86_64 specifiers, 'oldconfig' works consistently as well. For example i often switch over a 64-bit .config to 32-bit by doing this: make ARCH=i386 oldconfig that's a lot easier to do than to edit the .config. Similarly, i use this: make ARCH=x86_64 oldconfig to switch a .config over from 32-bit to 64-bit. Please make sure this still works with your patch applied. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:25 ` Ingo Molnar @ 2011-05-30 11:01 ` David Woodhouse 2011-05-30 11:04 ` Ingo Molnar 2011-05-31 8:53 ` Geert Uytterhoeven 1 sibling, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 11:01 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 2011-05-30 at 12:25 +0200, Ingo Molnar wrote: > Oh, that needs fixing then. Yeah, it was fixed in v2, which you should have received 15 minutes before sending your mail at 12:25 +0200? > make ARCH=i386 oldconfig > make ARCH=x86_64 oldconfig > to switch a .config over from 32-bit to 64-bit. Please make sure this > still works with your patch applied. Yes, that still works. The ARCH=i386 and ARCH=x86_64 behaviour should not have changed at all; this patch should *only* affect ARCH=x86 behaviour (and make ARCH=x86 the default for x86 hosts, unless specified on the make command line). -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:01 ` David Woodhouse @ 2011-05-30 11:04 ` Ingo Molnar 2011-05-30 11:12 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 11:04 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 12:25 +0200, Ingo Molnar wrote: > > Oh, that needs fixing then. > > Yeah, it was fixed in v2, which you should have received 15 minutes > before sending your mail at 12:25 +0200? That v2 changelog still seems to have an attitude though about the ARCH=i386 and ARCH=x86_64 modifiers (thoroughly debunked both by myself and others), so mind sending a v3 one which correctly and fairly describes the situation? (or ack my variant which ought to be pretty close) Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:04 ` Ingo Molnar @ 2011-05-30 11:12 ` David Woodhouse 2011-05-30 11:42 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 11:12 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 2011-05-30 at 13:04 +0200, Ingo Molnar wrote: > > That v2 changelog still seems to have an attitude though about the > ARCH=i386 and ARCH=x86_64 modifiers (thoroughly debunked both by > myself and others), so mind sending a v3 one which correctly and > fairly describes the situation? (or ack my variant which ought to be > pretty close) SIGWENCH; have to run. Back later. Can we make it something like "This version preserves the legacy ARCH=i386/ARCH=x86_64 behaviour for randconfig/oldconfig/all*config, although I believe that this *ought* to be removed in the future, in favour of a generic method of overriding config options — one that doesn't work *only* for one particular config setting (CONFIG_64BIT), and *only* on one architecture (there's no equivalent for mips/powerpc/s390/parisc/sparc to flip CONFIG_64BIT for you)." It's less of an 'attitude' but I think it clearly states the situation? -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:12 ` David Woodhouse @ 2011-05-30 11:42 ` Ingo Molnar 2011-05-30 11:55 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 11:42 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 13:04 +0200, Ingo Molnar wrote: > > > > That v2 changelog still seems to have an attitude though about the > > ARCH=i386 and ARCH=x86_64 modifiers (thoroughly debunked both by > > myself and others), so mind sending a v3 one which correctly and > > fairly describes the situation? (or ack my variant which ought to be > > pretty close) > > SIGWENCH; have to run. Back later. Can we make it something like > > "This version preserves the legacy ARCH=i386/ARCH=x86_64 behaviour for > randconfig/oldconfig/all*config, although I believe that this *ought* to > be removed in the future, in favour of a generic method of overriding > config options — one that doesn't work *only* for one particular config > setting (CONFIG_64BIT), and *only* on one architecture (there's no > equivalent for mips/powerpc/s390/parisc/sparc to flip CONFIG_64BIT for > you)." > > It's less of an 'attitude' but I think it clearly states the situation? Not sure we can actually remove it all that soon - people rely on it and seem to like it, me included! What kind of replacement are you suggesting? Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:42 ` Ingo Molnar @ 2011-05-30 11:55 ` David Woodhouse 2011-05-30 12:11 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 11:55 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel On Mon, 30 May 2011, Ingo Molnar wrote: > > What kind of replacement are you suggesting? I suspect that make CONFIG_64BIT=y CONFIG_SATA_MV=y whateverconfig ought to work for all the examples shown so far? -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:55 ` David Woodhouse @ 2011-05-30 12:11 ` Ingo Molnar 0 siblings, 0 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 12:11 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 30 May 2011, Ingo Molnar wrote: > > > > > What kind of replacement are you suggesting? > > I suspect that > make CONFIG_64BIT=y CONFIG_SATA_MV=y whateverconfig > > ought to work for all the examples shown so far? Well, some people will argue that: make ARCH=i386 whateverconfig is less typing than: make CONFIG_64BIT=y whateverconfig # set bitness make CONFIG_64BIT=y ARCH=x86 whateverconfig # set architecture and bitness but yes, in the long run i agree that 'ARCH=i386' would simply be a (legacy) shortcut for: CONFIG_64BIT=y ARCH=x86 and 'ARCH=x86_64' should be a (legacy) shortcut for: CONFIG_64BIT=n ARCH=x86 Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:25 ` Ingo Molnar 2011-05-30 11:01 ` David Woodhouse @ 2011-05-31 8:53 ` Geert Uytterhoeven 2011-05-31 10:48 ` Ingo Molnar 1 sibling, 1 reply; 89+ messages in thread From: Geert Uytterhoeven @ 2011-05-31 8:53 UTC (permalink / raw) To: Ingo Molnar; +Cc: David Woodhouse, x86, linux-kernel On Mon, May 30, 2011 at 12:25, Ingo Molnar <mingo@elte.hu> wrote: >> > I personally prefer 'make ARCH=i386 defconfig' and 'make ARCH=x86_64 >> > defconfig' because it's a nice conceptual equivalent to: >> > >> > make ARCH=arm defconfig >> > make ARCH=mips defconfig >> >> No, ARCH= is just for cross-compiling. If you're *on* an ARM or MIPS >> box, you don't need the ARCH= bit. > > Still note that 'make ARCH=arm defconfig' will just work fine even > without cross-building, so i often use just that if i want to see > what default core kernel options ARM (or MIPS) has enabled these > days. That's still the first part of "cross-building", so the issue is moot. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 8:53 ` Geert Uytterhoeven @ 2011-05-31 10:48 ` Ingo Molnar 0 siblings, 0 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 10:48 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: David Woodhouse, x86, linux-kernel * Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Mon, May 30, 2011 at 12:25, Ingo Molnar <mingo@elte.hu> wrote: > >> > I personally prefer 'make ARCH=i386 defconfig' and 'make ARCH=x86_64 > >> > defconfig' because it's a nice conceptual equivalent to: > >> > > >> > make ARCH=arm defconfig > >> > make ARCH=mips defconfig > >> > >> No, ARCH= is just for cross-compiling. If you're *on* an ARM or MIPS > >> box, you don't need the ARCH= bit. > > > > Still note that 'make ARCH=arm defconfig' will just work fine even > > without cross-building, so i often use just that if i want to see > > what default core kernel options ARM (or MIPS) has enabled these > > days. > > That's still the first part of "cross-building", so the issue is moot. The .config is sometimes the only bit i'm interested in - does an architecture's "most important defconfig" turn on a particular core kernel feature or not? I dont want to pick one of the 123 ARM defconfigs. (123 is the current upstream count of ARM defconfigs) Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 9:27 ` David Woodhouse 2011-05-30 9:53 ` Ingo Molnar @ 2011-05-30 10:40 ` Alexey Dobriyan 1 sibling, 0 replies; 89+ messages in thread From: Alexey Dobriyan @ 2011-05-30 10:40 UTC (permalink / raw) To: David Woodhouse; +Cc: Ingo Molnar, x86, linux-kernel On Mon, May 30, 2011 at 12:27 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 11:15 +0200, Ingo Molnar wrote: >> >> > I believe that this 'filtered randconfig' behaviour is now fairly much >> > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. >> >> I use "make ARCH=i386 defconfig" and "make ARCH=x86_64 defconfig" all >> the time. > > Good point. But shouldn't "make i386_defconfig" and "make > x86_64_defconfig" do that? No, because there is no point. make ARCH=i386 allnoconfig make ARCH=x86_64 allnoconfig make ARCH=i386 defconfig make ARCH=x86_64 defconfig make ARCH=i386 allmodconfig make ARCH=x86_64 allmodconfig are OK and are used this way and are consistent with other archs. Unification to death is not needed. ^ permalink raw reply [flat|nested] 89+ messages in thread
* [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig' 2011-05-30 9:15 ` Ingo Molnar 2011-05-30 9:27 ` David Woodhouse @ 2011-05-30 10:09 ` David Woodhouse 2011-06-24 13:37 ` Michal Marek 1 sibling, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 10:09 UTC (permalink / raw) To: Ingo Molnar; +Cc: x86, linux-kernel I wasted a bunch of time today because I'd taken a .config from my test machine and tried to build it, and the existing setting of CONFIG_X86_32 got changed to the host system's bitness which was 64-bit. This patch fixes that. Last time I tried to fix this bug, I had introduced a regression that broke: make ARCH=x86_64 randconfig make ARCH=i386 randconfig type of filtered-randconfig behavior which restricted randconfigs to 64-bit and 32-bit configs, respectively. This version fixes that so prior randconfig behavior is maintained, although if a "filtered randconfig" is desired it seems like it would be better to actually implement that properly, rather than relying on a hack which preserves the obsolete 'ARCH=i386' and 'ARCH=x86_64' legacy just to influence *one* of the many config options that might need to be hard-coded if you actually want a 'randconfig' that produces a useful end-result. 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 :) diff --git a/Makefile b/Makefile index 123d858..7b3b7c5 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 cc6c53a..1f206b0 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 6f98726..41cab70 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 -- dwmw2 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig' 2011-05-30 10:09 ` [PATCH v2] x86, kconfig: Pick up the .config arch version " David Woodhouse @ 2011-06-24 13:37 ` Michal Marek 2011-06-24 14:45 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Michal Marek @ 2011-06-24 13:37 UTC (permalink / raw) To: David Woodhouse; +Cc: Ingo Molnar, x86, linux-kernel On 30.5.2011 12:09, David Woodhouse wrote: > I wasted a bunch of time today because I'd taken a .config from my > test machine and tried to build it, and the existing setting of > CONFIG_X86_32 got changed to the host system's bitness which was > 64-bit. > > This patch fixes that. Last time I tried to fix this bug, I had > introduced a regression that broke: > > make ARCH=x86_64 randconfig > make ARCH=i386 randconfig > > type of filtered-randconfig behavior which restricted randconfigs to > 64-bit and 32-bit configs, respectively. > > This version fixes that so prior randconfig behavior is maintained, > although if a "filtered randconfig" is desired it seems like it would be > better to actually implement that properly, rather than relying on a > hack which preserves the obsolete 'ARCH=i386' and 'ARCH=x86_64' legacy > just to influence *one* of the many config options that might need to be > hard-coded if you actually want a 'randconfig' that produces a useful > end-result. > > 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 :) > > diff --git a/Makefile b/Makefile > index 123d858..7b3b7c5 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 cc6c53a..1f206b0 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" This breaks all{mod,yes}config on 32bit and allnoconfig on 64bit (and randconfig sometimes :)). The user expectation is that make defconfig/allmodconfig/allyesconfig builds a kernel for their architecture. You only handle defconfig below. Michal ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig' 2011-06-24 13:37 ` Michal Marek @ 2011-06-24 14:45 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-06-24 14:45 UTC (permalink / raw) To: Michal Marek; +Cc: Ingo Molnar, x86, linux-kernel On Fri, 2011-06-24 at 15:37 +0200, Michal Marek wrote: > > This breaks all{mod,yes}config on 32bit and allnoconfig on 64bit (and > randconfig sometimes :)). The user expectation is that make > defconfig/allmodconfig/allyesconfig builds a kernel for their > architecture. You only handle defconfig below. It's a broken expectation. Your architecture is x86. You are building the kernel in arch/x86. Your architecture is not "i386 with PAE" or "i386 without PAE" or "x86_64 with VT-x". Those are *configuration* options. If you want the Aunt Tillie "configure for my machine" option, that's something different. And uninteresting. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 8:57 ` David Woodhouse 2011-05-30 9:15 ` Ingo Molnar @ 2011-05-30 10:42 ` Ingo Molnar 2011-05-30 10:46 ` Ingo Molnar 2011-05-30 11:05 ` Arnd Bergmann 2 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 10:42 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 09:23 +0200, Ingo Molnar wrote: > > You thoroughly misunderstood my prior regression report, the problem > > with your patch was that your patch actually *broke* existing > > filtered-randconfig behavior, for example trying to get a 64-bit > > randconfig: > > > > make ARCH=x86_64 randconfig > > > > ... will today produce a 64-bit randconfig while with your old change > > applied it produced a 32-bit randconfig 50% of the time. > > I believe that this 'filtered randconfig' behaviour is now fairly much > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. Not really, there's also: make ARCH=i386 defconfig # writes 32-bit defconfig into .config make ARCH=x86_64 defconfig # writes 64-bit defconfig into .config make ARCH=i386 oldconfig # turns 64-bit .config int 32-bit equivalent make ARCH=x86_64 oldconfig # turns 32-bit .config int 64-bit equivalent And i use these variants myself, both as commands typed and in scripts, in addition to the randconfig variants: make ARCH=i386 randconfig # write 32-bit randconfig into .config make ARCH=x86_64 randconfig # write 64-bit randconfig into .config I'm pretty sure others are relying on these variants as well - they are fairly logical along several dimensions. So could we please fix the 'make oldconfig' behavior (which i fully agree with you should pick up the bitness from the .config) *without* regressing these other, working and useful cases? Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:42 ` [PATCH] Fix corruption of CONFIG_X86_32 " Ingo Molnar @ 2011-05-30 10:46 ` Ingo Molnar 2011-05-30 10:53 ` Theodore Tso 0 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 10:46 UTC (permalink / raw) To: David Woodhouse; +Cc: x86, linux-kernel * Ingo Molnar <mingo@elte.hu> wrote: > > I believe that this 'filtered randconfig' behaviour is now fairly > > much the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'. > > Not really, there's also: > > make ARCH=i386 defconfig # writes 32-bit defconfig into .config > make ARCH=x86_64 defconfig # writes 64-bit defconfig into .config > > make ARCH=i386 oldconfig # turns 64-bit .config int 32-bit equivalent > make ARCH=x86_64 oldconfig # turns 32-bit .config int 64-bit equivalent > > And i use these variants myself, both as commands typed and in > scripts, in addition to the randconfig variants: > > make ARCH=i386 randconfig # write 32-bit randconfig into .config > make ARCH=x86_64 randconfig # write 64-bit randconfig into .config > > I'm pretty sure others are relying on these variants as well - they > are fairly logical along several dimensions. Not to mention all the other *config variants, which work in a similar fashion: make ARCH=i386 allnoconfig # writes 32-bit all-disabled config into .config make ARCH=i386 allyesconfig # writes 32-bit all-enabled config into .config make ARCH=i386 allmodconfig # writes 32-bit all-modules config into .config make ARCH=x86_64 allnoconfig # writes 64-bit all-disabled config into .config make ARCH=x86_64 allyesconfig # writes 64-bit all-enabled config into .config make ARCH=x86_64 allmodconfig # writes 64-bit all-modules config into .config and i use them in this fashion both as typed commands and in scripts, and many other kernel developers are using them as well. So contrary to your claim there's *one dozen* very useful uses of this 'old' form - with no functional replacement AFAICS. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:46 ` Ingo Molnar @ 2011-05-30 10:53 ` Theodore Tso 2011-05-30 10:58 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: Theodore Tso @ 2011-05-30 10:53 UTC (permalink / raw) To: Ingo Molnar; +Cc: David Woodhouse, x86, linux-kernel I'd think that "make ARCH=x86_64 oldconfig" ... where the old configuration contained CONFIG_X86_32 should trigger a warning, if not an outright error that stops the build.... -- Ted ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:53 ` Theodore Tso @ 2011-05-30 10:58 ` Ingo Molnar 2011-05-30 11:04 ` Theodore Tso 2011-05-30 11:06 ` David Woodhouse 0 siblings, 2 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 10:58 UTC (permalink / raw) To: Theodore Tso; +Cc: David Woodhouse, x86, linux-kernel * Theodore Tso <tytso@MIT.EDU> wrote: > I'd think that "make ARCH=x86_64 oldconfig" > > ... where the old configuration contained CONFIG_X86_32 > should trigger a warning, if not an outright error that > stops the build.... That would be a rather sad regression for me: i use that command regularly to transform .configs that came in bugreports into a config suitable for a testbox that has a different bitness userspace installed. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:58 ` Ingo Molnar @ 2011-05-30 11:04 ` Theodore Tso 2011-05-30 11:30 ` Ingo Molnar ` (2 more replies) 2011-05-30 11:06 ` David Woodhouse 1 sibling, 3 replies; 89+ messages in thread From: Theodore Tso @ 2011-05-30 11:04 UTC (permalink / raw) To: Ingo Molnar; +Cc: David Woodhouse, x86, linux-kernel On May 30, 2011, at 6:58 AM, Ingo Molnar wrote: > > * Theodore Tso <tytso@MIT.EDU> wrote: > >> I'd think that "make ARCH=x86_64 oldconfig" >> >> ... where the old configuration contained CONFIG_X86_32 >> should trigger a warning, if not an outright error that >> stops the build.... > > That would be a rather sad regression for me: i use that command > regularly to transform .configs that came in bugreports into a config > suitable for a testbox that has a different bitness userspace > installed. OK, so to clarify, what you want is for ARCH=xxx to always override whatever is in .config? Are we all on the same page here? I thought David was arguing that what was in .config should always be more important, since he regards "ARCH=xxxx" as "legacy". Or maybe I'm missing something here.... since people seem to be slinging around examples what should or should not work, as opposed to simply saying, "ARCH=xxx" must always override all else, even in cases like "oldconfig", "randconfig", etc. Is that what the patch is going to do? All this talk of how it's OK for randconfig to give you i386 50% of the time even when ARCH=x86_64 is specified is confusing me? Maybe that was just intended to be sarcasm? -- Ted ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:04 ` Theodore Tso @ 2011-05-30 11:30 ` Ingo Molnar 2011-05-30 17:29 ` Randy Dunlap 2011-05-30 11:57 ` David Woodhouse 2011-05-30 19:03 ` David Woodhouse 2 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 11:30 UTC (permalink / raw) To: Theodore Tso; +Cc: David Woodhouse, x86, linux-kernel * Theodore Tso <tytso@MIT.EDU> wrote: > > On May 30, 2011, at 6:58 AM, Ingo Molnar wrote: > > > > > * Theodore Tso <tytso@MIT.EDU> wrote: > > > >> I'd think that "make ARCH=x86_64 oldconfig" > >> > >> ... where the old configuration contained CONFIG_X86_32 > >> should trigger a warning, if not an outright error that > >> stops the build.... > > > > That would be a rather sad regression for me: i use that command > > regularly to transform .configs that came in bugreports into a config > > suitable for a testbox that has a different bitness userspace > > installed. > > OK, so to clarify, what you want is for ARCH=xxx to always override > whatever is in .config? [...] If 'xxx' clearly signals both architecture and bitness then it should override both the architecture and the bitness of the .config - that's both common-sense and currently implemented (and relied on) behavior. 'ARCH=x86 oldconfig' should maintain bitness in the .config like it does today, because the 'xxx' only specifies the architecture. [ Btw., 'override the architecture' usecase is not just theoretical: i sometimes use this form to convert existing .config's *between* architectures, not just from 32-bit to 64-bit. So if i get an ARM bugreport that gives me the appearance of a core kernel bug i will often start by converting that to an x86 .config via 'make ARCH=x86_64 oldconfig'. ] > Are we all on the same page here? [...] I think this thread makes it rather clear that David and me are not on the same page. Not sure about you :) > [...] I thought David was arguing that what was in .config should > always be more important, since he regards "ARCH=xxxx" as "legacy". Well i (and current behavior) argue that what the user types actually has a meaning and a purpose and provides an override to other environmental data. > Or maybe I'm missing something here.... since people seem to be > slinging around examples what should or should not work, as opposed > to simply saying, "ARCH=xxx" must always override all else, even in > cases like "oldconfig", "randconfig", etc. Is that what the patch > is going to do? I said it from mail #1 on that "ARCH=xxx" must override the .config [except in cases like ARCH=x86 where 'xxx' does not imply bitness] and must modify/filter other typed arguments (randconfig/allnoconfig/allyesconfig, etc.) in an intuitive and common-sense fashion. > All this talk of how it's OK for randconfig to give you i386 50% of > the time even when ARCH=x86_64 is specified is confusing me? Maybe > that was just intended to be sarcasm? That was the original regression i reported to David. So yes, i do argue, and argued from day 1 on (which was 2 years ago) that 'ARCH=i386' and 'ARCH=x86_64' should override secondary sources of environment. It's just that David has not accepted my reasoning and has given a changelog that describes the topic in a rather one-sided fashion. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:30 ` Ingo Molnar @ 2011-05-30 17:29 ` Randy Dunlap 0 siblings, 0 replies; 89+ messages in thread From: Randy Dunlap @ 2011-05-30 17:29 UTC (permalink / raw) To: Ingo Molnar; +Cc: Theodore Tso, David Woodhouse, x86, linux-kernel On Mon, 30 May 2011 13:30:36 +0200 Ingo Molnar wrote: > > * Theodore Tso <tytso@MIT.EDU> wrote: > > > > > On May 30, 2011, at 6:58 AM, Ingo Molnar wrote: > > > > > > > > * Theodore Tso <tytso@MIT.EDU> wrote: > > > > > >> I'd think that "make ARCH=x86_64 oldconfig" > > >> > > >> ... where the old configuration contained CONFIG_X86_32 > > >> should trigger a warning, if not an outright error that > > >> stops the build.... > > > > > > That would be a rather sad regression for me: i use that command > > > regularly to transform .configs that came in bugreports into a config > > > suitable for a testbox that has a different bitness userspace > > > installed. > > > > OK, so to clarify, what you want is for ARCH=xxx to always override > > whatever is in .config? [...] > > If 'xxx' clearly signals both architecture and bitness then it should > override both the architecture and the bitness of the .config - > that's both common-sense and currently implemented (and relied on) > behavior. > > 'ARCH=x86 oldconfig' should maintain bitness in the .config like it > does today, because the 'xxx' only specifies the architecture. > > [ Btw., 'override the architecture' usecase is not just theoretical: > i sometimes use this form to convert existing .config's *between* > architectures, not just from 32-bit to 64-bit. So if i get an ARM > bugreport that gives me the appearance of a core kernel bug i will > often start by converting that to an x86 .config via 'make > ARCH=x86_64 oldconfig'. ] > > > Are we all on the same page here? [...] > > I think this thread makes it rather clear that David and me are not > on the same page. Not sure about you :) > > > [...] I thought David was arguing that what was in .config should > > always be more important, since he regards "ARCH=xxxx" as "legacy". > > Well i (and current behavior) argue that what the user types actually > has a meaning and a purpose and provides an override to other > environmental data. > > > Or maybe I'm missing something here.... since people seem to be > > slinging around examples what should or should not work, as opposed > > to simply saying, "ARCH=xxx" must always override all else, even in > > cases like "oldconfig", "randconfig", etc. Is that what the patch > > is going to do? > > I said it from mail #1 on that "ARCH=xxx" must override the .config > [except in cases like ARCH=x86 where 'xxx' does not imply bitness] > and must modify/filter other typed arguments > (randconfig/allnoconfig/allyesconfig, etc.) in an intuitive and > common-sense fashion. > > > All this talk of how it's OK for randconfig to give you i386 50% of > > the time even when ARCH=x86_64 is specified is confusing me? Maybe > > that was just intended to be sarcasm? > > That was the original regression i reported to David. So yes, i do > argue, and argued from day 1 on (which was 2 years ago) that > 'ARCH=i386' and 'ARCH=x86_64' should override secondary sources of > environment. AFAIK, command line options in kbuild always override other settings, so this should remain consistent. And yes, I also use lots of these same commands that Ingo uses, both in scripts and non-scripted (by hand). > It's just that David has not accepted my reasoning and has given a > changelog that describes the topic in a rather one-sided fashion. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:04 ` Theodore Tso 2011-05-30 11:30 ` Ingo Molnar @ 2011-05-30 11:57 ` David Woodhouse 2011-05-30 12:14 ` Ingo Molnar 2011-05-30 19:03 ` David Woodhouse 2 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 11:57 UTC (permalink / raw) To: Theodore Tso; +Cc: Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011, Theodore Tso wrote: > OK, so to clarify, what you want is for ARCH=xxx to always override > whatever is in .config? Are we all on the same page here? I thought > David was arguing that what was in .config should always be more > important, since he regards "ARCH=xxxx" as "legacy". I am saying that we should not have that redundancy at all. ATM we *only* have it for CONFIG_64BIT and *only* on x86, not others like ppc/sh/sparc etc. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:57 ` David Woodhouse @ 2011-05-30 12:14 ` Ingo Molnar 0 siblings, 0 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 12:14 UTC (permalink / raw) To: David Woodhouse; +Cc: Theodore Tso, x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 30 May 2011, Theodore Tso wrote: > > > OK, so to clarify, what you want is for ARCH=xxx to always override > > whatever is in .config? Are we all on the same page here? I thought > > David was arguing that what was in .config should always be more > > important, since he regards "ARCH=xxxx" as "legacy". > > I am saying that we should not have that redundancy at all. ATM we *only* > have it for CONFIG_64BIT and *only* on x86, not others like ppc/sh/sparc > etc. Even if we were ready to remove a feature that is 'only' available on 90%+ of development systems that kernel developers use today, we probably couldn't do it due to the upstream kernel regression policy anyway. Especially when there is no functionally equivalent replacement. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:04 ` Theodore Tso 2011-05-30 11:30 ` Ingo Molnar 2011-05-30 11:57 ` David Woodhouse @ 2011-05-30 19:03 ` David Woodhouse 2011-05-30 19:55 ` Ted Ts'o 2 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 19:03 UTC (permalink / raw) To: Theodore Tso; +Cc: Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011, Theodore Tso wrote: > All this talk of how it's OK for randconfig to give you i386 50% of the time > even when ARCH=x86_64 is specified is confusing me? Maybe that > was just intended to be sarcasm? No, I don't believe that was ever actually said at all. Certainly not this year. What was said was that with ARCH=x86, it's OK for randconfig to be random. And that the legacy trick of using ARCH=i386 or ARCH=x86_64 as a hack to override *just* CONFOG_64BIT, although nobody has posted a patch which removes or breaks that, probably ought to be deprecated in favour of a more generic way to override config options - one that doesn't work only for *one* config option, and only on *one* architecture. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 19:03 ` David Woodhouse @ 2011-05-30 19:55 ` Ted Ts'o 2011-05-30 20:12 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Ted Ts'o @ 2011-05-30 19:55 UTC (permalink / raw) To: David Woodhouse; +Cc: Ingo Molnar, x86, linux-kernel On Mon, May 30, 2011 at 08:03:08PM +0100, David Woodhouse wrote: > > And that the legacy trick of using ARCH=i386 or ARCH=x86_64 as a hack to > override *just* CONFOG_64BIT, although nobody has posted a patch which > removes or breaks that, probably ought to be deprecated in favour of a > more generic way to override config options - one that doesn't work only > for *one* config option, and only on *one* architecture. So I could imagine two ways of doing this. One would be a new file, .config-fixed, that contains a series of "CONFIG_XXX=[ymn]" which would have to be satisfied and which override what allyesconfig/allnoconfig/randconfig would otherwise do. The other way would be some kind of new tagging in the .config file itself, e.g.: CONFIG_64BIT=y # FIXED There are all sorts of interesting design questions hidden in here, of course, including what if the fixedpoint declarations (whether done via a separate file or via tags in .config) are mutually inconsistent. - Ted ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 19:55 ` Ted Ts'o @ 2011-05-30 20:12 ` David Woodhouse 2011-05-30 22:39 ` [PATCH] Enable 'make CONFIG_FOO=y oldconfig' David Woodhouse ` (2 more replies) 0 siblings, 3 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-30 20:12 UTC (permalink / raw) To: Ted Ts'o; +Cc: Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011, Ted Ts'o wrote: > So I could imagine two ways of doing this. One would be a new file, > .config-fixed, that contains a series of "CONFIG_XXX=[ymn]" which > would have to be satisfied and which override what > allyesconfig/allnoconfig/randconfig would otherwise do. Which is apparently what KCONFIG_ALLCONFIG already does? It doesn't work for choices, but it's still fine for setting/clearing CONFIG_64BIT. We'll want to make it simpler to use - so you really can do something like make CONFIG_64BIT=n randconfig make CONFIG_64BIT=n allmodconfig make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig etc. without having to create a text file. But that's not hard. A simple implementation might just *make* a file with the options on the command line and point KCONFIG_ALLCONFIG at it to start with, although there are probably cleaner ways to implement it. And then this legacy trick of using the obsolete $ARCH settings to override the setting of CONFIG_64BIT can be deprecated. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* [PATCH] Enable 'make CONFIG_FOO=y oldconfig' 2011-05-30 20:12 ` David Woodhouse @ 2011-05-30 22:39 ` David Woodhouse 2011-05-31 0:24 ` Arnaud Lacombe 2011-05-31 1:44 ` [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' Ted Ts'o 2011-05-31 7:53 ` Ingo Molnar 2 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 22:39 UTC (permalink / raw) To: Ted Ts'o; +Cc: Ingo Molnar, x86, linux-kernel, linux-kbuild This allows you to set (and clear) config options on the make command line, for all config targets. For example: make CONFIG_64BIT=n randconfig make CONFIG_64BIT=n allmodconfig make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c index 006ad81..2b91e3b 100644 --- a/scripts/kconfig/conf.c +++ b/scripts/kconfig/conf.c @@ -456,7 +456,7 @@ static struct option long_opts[] = { {NULL, 0, NULL, 0} }; -int main(int ac, char **av) +int main(int ac, char **av, char **ep) { int opt; const char *name; @@ -563,6 +563,11 @@ int main(int ac, char **av) break; } + for ( ; *ep; ep++) { + if (!strncmp(*ep, CONFIG_, strlen(CONFIG_))) + conf_set_symbol_from_env(*ep); + } + if (sync_kconfig) { if (conf_get_changed()) { name = getenv("KCONFIG_NOSILENTUPDATE"); diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 61c35bf..e8ff902 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -338,6 +338,47 @@ setsym: return 0; } +void conf_set_symbol_from_env(char *str) +{ + char *p = strchr(str, '='); + struct symbol *sym; + int def = S_DEF_USER; + int def_flags = SYMBOL_DEF << def; + + if (!p) + return; + + *p = 0; + sym = sym_find(str + strlen(CONFIG_)); + *p++ = '='; + + if (!sym) + return; + + if (!sym_set_string_value(sym, p)) + return; + conf_message("CONFIG_%s set to %s from environment", sym->name, p); + if (sym && sym_is_choice_value(sym)) { + struct symbol *cs = prop_get_symbol(sym_get_choice_prop(sym)); + switch (sym->def[def].tri) { + case no: + break; + case mod: + if (cs->def[def].tri == yes) { + conf_warning("%s creates inconsistent choice state", sym->name); + cs->flags &= ~def_flags; + } + break; + case yes: + if (cs->def[def].tri != no) + conf_warning("override: %s changes choice state", sym->name); + cs->def[def].val = sym; + break; + } + cs->def[def].tri = EXPR_OR(cs->def[def].tri, sym->def[def].tri); + } +} + int conf_read(const char *name) { struct symbol *sym, *choice_sym; diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index febf0c9..bf6fade 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -91,6 +91,7 @@ char *conf_get_default_confname(void); void sym_set_change_count(int count); void sym_add_change_count(int count); void conf_set_all_new_symbols(enum conf_def_mode mode); +void conf_set_symbol_from_env(char *); /* confdata.c and expr.c */ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) -- dwmw2 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig' 2011-05-30 22:39 ` [PATCH] Enable 'make CONFIG_FOO=y oldconfig' David Woodhouse @ 2011-05-31 0:24 ` Arnaud Lacombe 2011-05-31 15:48 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-05-31 0:24 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild Hi, On Mon, May 30, 2011 at 6:39 PM, David Woodhouse <dwmw2@infradead.org> wrote: > This allows you to set (and clear) config options on the make command > line, for all config targets. For example: > > make CONFIG_64BIT=n randconfig > make CONFIG_64BIT=n allmodconfig > make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > This does not seem to work with: % make CONFIG_ARCH_OMAP=y ARCH=arm allnoconfig HOSTCC scripts/kconfig/conf.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allnoconfig Kconfig # # configuration written to .config # % grep CONFIG_ARCH_OMAP .config # CONFIG_ARCH_OMAP is not set It would seem that the underlying symbol is not visible, triggering the failure of sym_set_tristate_value(). - Arnaud > diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c > index 006ad81..2b91e3b 100644 > --- a/scripts/kconfig/conf.c > +++ b/scripts/kconfig/conf.c > @@ -456,7 +456,7 @@ static struct option long_opts[] = { > {NULL, 0, NULL, 0} > }; > > -int main(int ac, char **av) > +int main(int ac, char **av, char **ep) > { > int opt; > const char *name; > @@ -563,6 +563,11 @@ int main(int ac, char **av) > break; > } > > + for ( ; *ep; ep++) { > + if (!strncmp(*ep, CONFIG_, strlen(CONFIG_))) > + conf_set_symbol_from_env(*ep); > + } > + > if (sync_kconfig) { > if (conf_get_changed()) { > name = getenv("KCONFIG_NOSILENTUPDATE"); > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c > index 61c35bf..e8ff902 100644 > --- a/scripts/kconfig/confdata.c > +++ b/scripts/kconfig/confdata.c > @@ -338,6 +338,47 @@ setsym: > return 0; > } > > +void conf_set_symbol_from_env(char *str) > +{ > + char *p = strchr(str, '='); > + struct symbol *sym; > + int def = S_DEF_USER; > + int def_flags = SYMBOL_DEF << def; > + > + if (!p) > + return; > + > + *p = 0; > + sym = sym_find(str + strlen(CONFIG_)); > + *p++ = '='; > + > + if (!sym) > + return; > + > + if (!sym_set_string_value(sym, p)) > + return; > + conf_message("CONFIG_%s set to %s from environment", sym->name, p); > + if (sym && sym_is_choice_value(sym)) { > + struct symbol *cs = prop_get_symbol(sym_get_choice_prop(sym)); > + switch (sym->def[def].tri) { > + case no: > + break; > + case mod: > + if (cs->def[def].tri == yes) { > + conf_warning("%s creates inconsistent choice state", sym->name); > + cs->flags &= ~def_flags; > + } > + break; > + case yes: > + if (cs->def[def].tri != no) > + conf_warning("override: %s changes choice state", sym->name); > + cs->def[def].val = sym; > + break; > + } > + cs->def[def].tri = EXPR_OR(cs->def[def].tri, sym->def[def].tri); > + } > +} > + > int conf_read(const char *name) > { > struct symbol *sym, *choice_sym; > diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h > index febf0c9..bf6fade 100644 > --- a/scripts/kconfig/lkc.h > +++ b/scripts/kconfig/lkc.h > @@ -91,6 +91,7 @@ char *conf_get_default_confname(void); > void sym_set_change_count(int count); > void sym_add_change_count(int count); > void conf_set_all_new_symbols(enum conf_def_mode mode); > +void conf_set_symbol_from_env(char *); > > /* confdata.c and expr.c */ > static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) > > > -- > 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 > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig' 2011-05-31 0:24 ` Arnaud Lacombe @ 2011-05-31 15:48 ` David Woodhouse 2011-05-31 16:12 ` Arnaud Lacombe 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-31 15:48 UTC (permalink / raw) To: Arnaud Lacombe; +Cc: Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On Mon, 2011-05-30 at 20:24 -0400, Arnaud Lacombe wrote: > It would seem that the underlying symbol is not visible, triggering > the failure of sym_set_tristate_value(). Yes, this only lets you set *visible* symbols. If the symbol you're interested in is not visible because some of its dependencies are not set, it doesn't go and automatically enable those. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig' 2011-05-31 15:48 ` David Woodhouse @ 2011-05-31 16:12 ` Arnaud Lacombe 2011-06-24 13:49 ` Michal Marek 0 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-05-31 16:12 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild Hi, On Tue, May 31, 2011 at 11:48 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 20:24 -0400, Arnaud Lacombe wrote: >> It would seem that the underlying symbol is not visible, triggering >> the failure of sym_set_tristate_value(). > > Yes, this only lets you set *visible* symbols. If the symbol you're > interested in is not visible because some of its dependencies are not > set, it doesn't go and automatically enable those. > As for this choice, it *is* visible. You are missing a call to `sym_calc_value()' (actually sym_calc_visibility() but it is not exported) before the conditional to correct the visibility. Beside that, if the environment is to influence the configuration unconditionally, it would rather be better to do that when the Kconfig are parsed. - Arnaud > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@intel.com Intel Corporation > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig' 2011-05-31 16:12 ` Arnaud Lacombe @ 2011-06-24 13:49 ` Michal Marek 2011-07-29 23:32 ` [PATCH v2] " David Woodhouse 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse 0 siblings, 2 replies; 89+ messages in thread From: Michal Marek @ 2011-06-24 13:49 UTC (permalink / raw) To: Arnaud Lacombe Cc: David Woodhouse, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On 31.5.2011 18:12, Arnaud Lacombe wrote: > Hi, > > On Tue, May 31, 2011 at 11:48 AM, David Woodhouse<dwmw2@infradead.org> wrote: >> On Mon, 2011-05-30 at 20:24 -0400, Arnaud Lacombe wrote: >>> It would seem that the underlying symbol is not visible, triggering >>> the failure of sym_set_tristate_value(). >> >> Yes, this only lets you set *visible* symbols. If the symbol you're >> interested in is not visible because some of its dependencies are not >> set, it doesn't go and automatically enable those. >> > As for this choice, it *is* visible. You are missing a call to > `sym_calc_value()' (actually sym_calc_visibility() but it is not > exported) before the conditional to correct the visibility. David, will you post a patch with this fix? $ make CONFIG_ARCH_OMAP=y ARCH=arm allnoconfig $ grep CONFIG_ARCH_OMAP .config # CONFIG_ARCH_OMAP is not set vs. $ echo CONFIG_ARCH_OMAP=y >all.config $ make ARCH=arm allnoconfig $ grep CONFIG_ARCH_OMAP .config CONFIG_ARCH_OMAP=y ... > Beside that, if the environment is to influence the configuration > unconditionally, it would rather be better to do that when the Kconfig > are parsed. I don't quite understand what you mean here. The environment variables are evaluated right after the potential all*.config file is read. Do you think there is a problem with that? Michal ^ permalink raw reply [flat|nested] 89+ messages in thread
* [PATCH v2] Enable 'make CONFIG_FOO=y oldconfig' 2011-06-24 13:49 ` Michal Marek @ 2011-07-29 23:32 ` David Woodhouse 2011-07-30 1:15 ` Arnaud Lacombe 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse 1 sibling, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-07-29 23:32 UTC (permalink / raw) To: Michal Marek Cc: Arnaud Lacombe, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa This allows you to set (and clear) config options on the make command line, for all config targets. For example: make CONFIG_64BIT=n randconfig make CONFIG_64BIT=n allmodconfig make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- v2: Add call to sym_calc_value() before sym_set_string_value(), to set symbol visibility. 'make ARCH=arm CONFIG_ARCH_OMAP=y allnoconfig' should work correctly now. scripts/kconfig/conf.c | 7 ++++++- scripts/kconfig/confdata.c | 42 ++++++++++++++++++++++++++++++++++++++++++ scripts/kconfig/lkc.h | 1 + 3 files changed, 49 insertions(+), 1 deletions(-) diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c index 006ad81..2b91e3b 100644 --- a/scripts/kconfig/conf.c +++ b/scripts/kconfig/conf.c @@ -456,7 +456,7 @@ static struct option long_opts[] = { {NULL, 0, NULL, 0} }; -int main(int ac, char **av) +int main(int ac, char **av, char **ep) { int opt; const char *name; @@ -563,6 +563,11 @@ int main(int ac, char **av) break; } + for ( ; *ep; ep++) { + if (!strncmp(*ep, CONFIG_, strlen(CONFIG_))) + conf_set_symbol_from_env(*ep); + } + if (sync_kconfig) { if (conf_get_changed()) { name = getenv("KCONFIG_NOSILENTUPDATE"); diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 2bafd9a..ada3c4b 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -338,6 +338,48 @@ setsym: return 0; } +void conf_set_symbol_from_env(char *str) +{ + char *p = strchr(str, '='); + struct symbol *sym; + int def = S_DEF_USER; + int def_flags = SYMBOL_DEF << def; + + if (!p) + return; + + *p = 0; + sym = sym_find(str + strlen(CONFIG_)); + *p++ = '='; + + if (!sym) + return; + + sym_calc_value(sym); + if (!sym_set_string_value(sym, p)) + return; + conf_message("CONFIG_%s set to %s from environment", sym->name, p); + if (sym && sym_is_choice_value(sym)) { + struct symbol *cs = prop_get_symbol(sym_get_choice_prop(sym)); + switch (sym->def[def].tri) { + case no: + break; + case mod: + if (cs->def[def].tri == yes) { + conf_warning("%s creates inconsistent choice state", sym->name); + cs->flags &= ~def_flags; + } + break; + case yes: + if (cs->def[def].tri != no) + conf_warning("override: %s changes choice state", sym->name); + cs->def[def].val = sym; + break; + } + cs->def[def].tri = EXPR_OR(cs->def[def].tri, sym->def[def].tri); + } +} + int conf_read(const char *name) { struct symbol *sym, *choice_sym; diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index f34a0a9..fc2f3ad 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -89,6 +89,7 @@ char *conf_get_default_confname(void); void sym_set_change_count(int count); void sym_add_change_count(int count); void conf_set_all_new_symbols(enum conf_def_mode mode); +void conf_set_symbol_from_env(char *); /* confdata.c and expr.c */ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) -- 1.7.6 -- dwmw2 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v2] Enable 'make CONFIG_FOO=y oldconfig' 2011-07-29 23:32 ` [PATCH v2] " David Woodhouse @ 2011-07-30 1:15 ` Arnaud Lacombe 2011-07-30 9:04 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 1:15 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa Hi, On Fri, Jul 29, 2011 at 7:32 PM, David Woodhouse <dwmw2@infradead.org> wrote: > This allows you to set (and clear) config options on the make command > line, for all config targets. For example: > > make CONFIG_64BIT=n randconfig > make CONFIG_64BIT=n allmodconfig > make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig > Technically, kconfig already provides you all the interfaces to set symbol to a given value, for `randconfig' via "rand.config", for `all{yes,mod,no}config', via all.{yes,mod,no}config, for oldconfig via .config. Why another interface ? > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> > --- > v2: Add call to sym_calc_value() before sym_set_string_value(), to set > symbol visibility. 'make ARCH=arm CONFIG_ARCH_OMAP=y allnoconfig' > should work correctly now. > > scripts/kconfig/conf.c | 7 ++++++- > scripts/kconfig/confdata.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > scripts/kconfig/lkc.h | 1 + > 3 files changed, 49 insertions(+), 1 deletions(-) > > diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c > index 006ad81..2b91e3b 100644 > --- a/scripts/kconfig/conf.c > +++ b/scripts/kconfig/conf.c > @@ -456,7 +456,7 @@ static struct option long_opts[] = { > {NULL, 0, NULL, 0} > }; > > -int main(int ac, char **av) > +int main(int ac, char **av, char **ep) > { > int opt; > const char *name; > @@ -563,6 +563,11 @@ int main(int ac, char **av) > break; > } > > + for ( ; *ep; ep++) { > + if (!strncmp(*ep, CONFIG_, strlen(CONFIG_))) > + conf_set_symbol_from_env(*ep); > + } > + > if (sync_kconfig) { > if (conf_get_changed()) { > name = getenv("KCONFIG_NOSILENTUPDATE"); > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c > index 2bafd9a..ada3c4b 100644 > --- a/scripts/kconfig/confdata.c > +++ b/scripts/kconfig/confdata.c > @@ -338,6 +338,48 @@ setsym: > return 0; > } > > +void conf_set_symbol_from_env(char *str) > +{ > + char *p = strchr(str, '='); > + struct symbol *sym; > + int def = S_DEF_USER; > + int def_flags = SYMBOL_DEF << def; > + > + if (!p) > + return; the environment should already gives you the guarantee that `p' won't be NULL. If that's not the case, the environment is likely to be broken. > + > + *p = 0; > + sym = sym_find(str + strlen(CONFIG_)); > + *p++ = '='; > + > + if (!sym) > + return; > + > + sym_calc_value(sym); > + if (!sym_set_string_value(sym, p)) > + return; > + conf_message("CONFIG_%s set to %s from environment", sym->name, p); please do not hardcode the prefix. > + if (sym && sym_is_choice_value(sym)) { you do not need to test for the validity of a pointer you unconditionally dereference right before :) > + struct symbol *cs = prop_get_symbol(sym_get_choice_prop(sym)); > + switch (sym->def[def].tri) { > + case no: > + break; > + case mod: > + if (cs->def[def].tri == yes) { > + conf_warning("%s creates inconsistent choice state", sym->name); > + cs->flags &= ~def_flags; > + } > + break; > + case yes: > + if (cs->def[def].tri != no) > + conf_warning("override: %s changes choice state", sym->name); > + cs->def[def].val = sym; > + break; > + } > + cs->def[def].tri = EXPR_OR(cs->def[def].tri, sym->def[def].tri); > + } > +} > + > int conf_read(const char *name) > { > struct symbol *sym, *choice_sym; > diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h > index f34a0a9..fc2f3ad 100644 > --- a/scripts/kconfig/lkc.h > +++ b/scripts/kconfig/lkc.h > @@ -89,6 +89,7 @@ char *conf_get_default_confname(void); > void sym_set_change_count(int count); > void sym_add_change_count(int count); > void conf_set_all_new_symbols(enum conf_def_mode mode); > +void conf_set_symbol_from_env(char *); > > /* confdata.c and expr.c */ > static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) > -- > 1.7.6 > > > -- > dwmw2 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v2] Enable 'make CONFIG_FOO=y oldconfig' 2011-07-30 1:15 ` Arnaud Lacombe @ 2011-07-30 9:04 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-30 9:04 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa On Fri, 2011-07-29 at 21:15 -0400, Arnaud Lacombe wrote: > Technically, kconfig already provides you all the interfaces to set > symbol to a given value, for `randconfig' via "rand.config", for > `all{yes,mod,no}config', via all.{yes,mod,no}config, for oldconfig via > .config. Why another interface ? It's useful for some people to be able to do this as simply as possible from the command line, and they get very upset if you suggest that they might use those other methods instead. In particular, some people currently use the legacy 'ARCH=i386' and 'ARCH=x86_64' settings on the command line in order to switch the value of CONFIG_64BIT on and off for various *config targets¹. In fact, I think that's the *only* thing that those legacy ARCH settings still do; they could (technically, at least) be killed off if we have an alternative way of doing it. This provides an alternative, more generic way of doing it for *all* config options; not just CONFIG_64BIT and not just for x86. (¹ Note: in fact, *many* people use 'ARCH=i386' and 'ARCH=x86_64', but not really for this purpose. Most people use it just to work around the bug I fixed in my other patch — that the value of CONFIG_64BIT is *always* overridden to match the build host, unless you do *something* on the command line to work around it. Just ARCH=x86 would suffice, since that makes CONFIG_64BIT work sanely again.) > > +void conf_set_symbol_from_env(char *str) > > +{ > > + char *p = strchr(str, '='); > > + struct symbol *sym; > > + int def = S_DEF_USER; > > + int def_flags = SYMBOL_DEF << def; > > + > > + if (!p) > > + return; > the environment should already gives you the guarantee that `p' won't > be NULL. If that's not the case, the environment is likely to be > broken. Yes, that's true. Nevertheless, I've seen broken environments — there's no harm in being robust. We can't be robust in the face of *all* the ways the environment could screw up, of course, but this check doesn't really hurt. Especially given that the getenv() isn't even *in* this function, so this function is even more justified in checking its inputs. > > + > > + *p = 0; > > + sym = sym_find(str + strlen(CONFIG_)); > > + *p++ = '='; > > + > > + if (!sym) > > + return; > > + > > + sym_calc_value(sym); > > + if (!sym_set_string_value(sym, p)) > > + return; > > + conf_message("CONFIG_%s set to %s from environment", sym->name, p); > please do not hardcode the prefix. OK. > > + if (sym && sym_is_choice_value(sym)) { > you do not need to test for the validity of a pointer you > unconditionally dereference right before :) That's a copy-and-paste from identical code in conf_read_simple(), which I suppose should be factored out into a separate function. if I really understood what it was doing I'd be able to suggest a sane name... sym_validate_choice_state() perhaps? I'll do that. > > + struct symbol *cs = prop_get_symbol(sym_get_choice_prop(sym)); > > + switch (sym->def[def].tri) { > > + case no: > > + break; > > + case mod: > > + if (cs->def[def].tri == yes) { > > + conf_warning("%s creates inconsistent choice state", sym->name); > > + cs->flags &= ~def_flags; > > + } > > + break; > > + case yes: > > + if (cs->def[def].tri != no) > > + conf_warning("override: %s changes choice state", sym->name); > > + cs->def[def].val = sym; > > + break; > > + } > > + cs->def[def].tri = EXPR_OR(cs->def[def].tri, sym->def[def].tri); > > + } > > +} > > + -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-06-24 13:49 ` Michal Marek 2011-07-29 23:32 ` [PATCH v2] " David Woodhouse @ 2011-07-30 0:49 ` David Woodhouse 2011-07-30 1:26 ` Arnaud Lacombe ` (3 more replies) 1 sibling, 4 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-30 0:49 UTC (permalink / raw) To: Michal Marek Cc: Arnaud Lacombe, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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" ---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 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse @ 2011-07-30 1:26 ` Arnaud Lacombe 2011-07-30 15:52 ` Arnaud Lacombe ` (2 subsequent siblings) 3 siblings, 0 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 1:26 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, 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. > 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 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT @ 2011-07-30 1:26 ` Arnaud Lacombe 0 siblings, 0 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 1:26 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, 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. > 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 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 1:26 ` Arnaud Lacombe (?) @ 2011-07-30 8:37 ` David Woodhouse 2011-07-30 15:21 ` Arnaud Lacombe -1 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-07-30 8:37 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 8:37 ` David Woodhouse @ 2011-07-30 15:21 ` Arnaud Lacombe 0 siblings, 0 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 15:21 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa Hi On Sat, Jul 30, 2011 at 4:37 AM, David Woodhouse <dwmw2@infradead.org> wrote: > 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. Just to make my point clearer, here is what I'd be advocating: diff --git a/Makefile b/Makefile index b927e75..a15b773 100644 --- a/Makefile +++ b/Makefile @@ -192,7 +192,11 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ # Default value for CROSS_COMPILE is not to prefix executables # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile export KBUILD_BUILDHOST := $(SUBARCH) +ifeq ($(shell test -e .config && echo n),n) ARCH ?= $(SUBARCH) +else +ARCH ?= $(shell sed '/^\# Linux\/\(.*\) .* Kernel Configuration/!d; s//\1/' .config) +endif CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%) this work but smells hackish. - Arnaud > 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. > > -- > dwmw2 > > ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse 2011-07-30 1:26 ` Arnaud Lacombe @ 2011-07-30 15:52 ` Arnaud Lacombe 2011-07-30 16:19 ` David Woodhouse 2011-07-31 19:40 ` Arnaud Lacombe 2011-07-31 5:18 ` Arnaud Lacombe 2011-07-31 21:47 ` Arnaud Lacombe 3 siblings, 2 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 15:52 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, 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/ \ this is breaking ARCH=um. - Arnaud ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 15:52 ` Arnaud Lacombe @ 2011-07-30 16:19 ` David Woodhouse 2011-07-30 16:33 ` Arnaud Lacombe 2011-07-31 19:40 ` Arnaud Lacombe 1 sibling, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-07-30 16:19 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 16:19 ` David Woodhouse @ 2011-07-30 16:33 ` Arnaud Lacombe 2011-07-30 18:59 ` H. Peter Anvin 0 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 16:33 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 16:33 ` Arnaud Lacombe @ 2011-07-30 18:59 ` H. Peter Anvin 2011-07-30 20:58 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: H. Peter Anvin @ 2011-07-30 18:59 UTC (permalink / raw) To: Arnaud Lacombe Cc: David Woodhouse, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild 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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 18:59 ` H. Peter Anvin @ 2011-07-30 20:58 ` David Woodhouse 2011-07-30 22:03 ` H. Peter Anvin 2011-07-30 22:21 ` Arnaud Lacombe 0 siblings, 2 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-30 20:58 UTC (permalink / raw) To: H. Peter Anvin Cc: Arnaud Lacombe, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On Sat, 2011-07-30 at 11:59 -0700, H. Peter Anvin wrote: > 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?) In the context of a kernel build that's meaningless though. One kernel can support *many* types of userspace. I've just been playing with ARCH=um. It looks like the current state, even before my patch, is that 'make ARCH=um SUBARCH=x86' is broken. I'll work on a patch to fix that, and then it will be fine when the default for SUBARCH changes to be "x86". (Another option is to make SUBARCH default to x86 *only* if ARCH!=um, and still use the legacy SUBARCH values when ARCH=um. But I'm not overly keen on that approach.) Fixing um to work with ARCH=x86 *ought* to be as simple as doing something like this: --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -12,6 +12,15 @@ OS := $(shell uname -s) # features. SHELL := /bin/bash +# The i386/x86_64 merge hasn't really happened in um-land yet. Fake it. +ifeq ($(SUBARCH),x86) +ifeq ($(CONFIG_64BIT),y) +SUBARCH := x86_64 +else +SUBARCH := i386 +endif +endif + filechk_gen_header = $< core-y += $(ARCH_DIR)/kernel/ \ .. but that gives me weird behaviour where it just keeps running silentoldconfig over and over again. This patch *does* work, but I'll see if I can make it simpler... diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86 index d31ecf3..576b732 100644 --- a/arch/um/Kconfig.x86 +++ b/arch/um/Kconfig.x86 @@ -19,8 +19,8 @@ config UML_X86 select GENERIC_FIND_FIRST_BIT config 64BIT - bool - default SUBARCH = "x86_64" + bool "64-bit kernel" if SUBARCH = "x86" + default SUBARCH != "i386" config X86_32 def_bool !64BIT diff --git a/arch/um/Makefile b/arch/um/Makefile index fab8121..562c6cb 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -12,6 +12,17 @@ OS := $(shell uname -s) # features. SHELL := /bin/bash +# The i386/x86_64 merge hasn't really happened in um-land yet. Fake it. +ifeq ($(SUBARCH),x86) +ifeq ($(CONFIG_64BIT),y) +UMSUBARCH := x86_64 +else +UMSUBARCH := i386 +endif +else +UMSUBARCH := $(SUBARCH) +endif + filechk_gen_header = $< core-y += $(ARCH_DIR)/kernel/ \ @@ -24,11 +35,11 @@ include $(srctree)/$(ARCH_DIR)/Makefile-skas SHARED_HEADERS := $(ARCH_DIR)/include/shared ARCH_INCLUDE := -I$(srctree)/$(SHARED_HEADERS) -ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH)/shared +ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(UMSUBARCH)/shared ifneq ($(KBUILD_SRC),) ARCH_INCLUDE += -I$(SHARED_HEADERS) endif -KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH) +KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(UMSUBARCH) # -Dvmap=kernel_vmap prevents anything from referencing the libpcap.o symbol so # named - it's a common symbol in libpcap, so we get a binary which crashes. @@ -38,7 +49,7 @@ KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH) # # These apply to USER_CFLAGS to. -KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(SUBARCH)\" \ +KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(UMSUBARCH)\" \ $(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap \ -Din6addr_loopback=kernel_in6addr_loopback \ -Din6addr_any=kernel_in6addr_any @@ -49,7 +60,7 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\ $(patsubst -I%,,$(KBUILD_CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \ $(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 -include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH) +include $(srctree)/$(ARCH_DIR)/Makefile-$(UMSUBARCH) #This will adjust *FLAGS accordingly to the platform. include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS) @@ -128,8 +139,8 @@ archclean: # Generated files -$(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s: FORCE - $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(SUBARCH) $@ +$(ARCH_DIR)/sys-$(UMSUBARCH)/user-offsets.s: FORCE + $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(UMSUBARCH) $@ define filechk_gen-asm-offsets (set -e; \ @@ -144,11 +155,11 @@ define filechk_gen-asm-offsets echo ""; ) endef -$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s +$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(UMSUBARCH)/user-offsets.s $(call filechk,gen-asm-offsets) $(SHARED_HEADERS)/kern_constants.h: $(Q)mkdir -p $(dir $@) $(Q)echo '#include "../../../../include/generated/asm-offsets.h"' >$@ -export SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH +export SUBARCH UMSUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386 index 302cbe5..b66063b 100644 --- a/arch/um/Makefile-i386 +++ b/arch/um/Makefile-i386 @@ -5,22 +5,22 @@ TOP_ADDR := $(CONFIG_TOP_ADDR) START := 0x8048000 LDFLAGS += -m elf_i386 -ELF_ARCH := $(SUBARCH) -ELF_FORMAT := elf32-$(SUBARCH) +ELF_ARCH := $(UMSUBARCH) +ELF_FORMAT := elf32-$(UMSUBARCH) OBJCOPYFLAGS := -O binary -R .note -R .comment -S HEADER_ARCH := x86 CHECKFLAGS += -D__i386__ -ifeq ("$(origin SUBARCH)", "command line") -ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)") +#ifeq ("$(origin SUBARCH)", "command line") +#ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)") KBUILD_CFLAGS += $(call cc-option,-m32) KBUILD_AFLAGS += $(call cc-option,-m32) LINK-y += $(call cc-option,-m32) UML_OBJCOPYFLAGS += -F $(ELF_FORMAT) export LDFLAGS HOSTCFLAGS HOSTLDFLAGS UML_OBJCOPYFLAGS -endif -endif +#endif +#endif # First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y. include $(srctree)/arch/x86/Makefile_32.cpu diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile index b33f4df..c1a2ca3 100644 --- a/arch/um/os-Linux/Makefile +++ b/arch/um/os-Linux/Makefile @@ -5,7 +5,7 @@ obj-y = aio.o execvp.o file.o helper.o irq.o main.o mem.o process.o \ registers.o sigio.o signal.o start_up.o time.o tty.o uaccess.o \ - umid.o tls.o user_syms.o util.o drivers/ sys-$(SUBARCH)/ skas/ + umid.o tls.o user_syms.o util.o drivers/ sys-$(UMSUBARCH)/ skas/ obj-$(CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA) += elf_aux.o -- dwmw2 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 20:58 ` David Woodhouse @ 2011-07-30 22:03 ` H. Peter Anvin 2011-07-30 22:17 ` David Woodhouse 2011-07-30 22:21 ` Arnaud Lacombe 1 sibling, 1 reply; 89+ messages in thread From: H. Peter Anvin @ 2011-07-30 22:03 UTC (permalink / raw) To: David Woodhouse Cc: Arnaud Lacombe, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On 07/30/2011 01:58 PM, David Woodhouse wrote: > > In the context of a kernel build that's meaningless though. One kernel > can support *many* types of userspace. > It isn't meaningless for exactly that reason. For example, "make ARCH=x86 USERARCH=i386" and "make ARCH=x86 USERARCH=x86_64" both make sense. Similarly, "make ARCH=um USERARCH=i386" is different from "make ARCH=um USERARCH=x86_64". -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:03 ` H. Peter Anvin @ 2011-07-30 22:17 ` David Woodhouse 2011-07-30 22:21 ` H. Peter Anvin 2011-07-30 22:24 ` Arnaud Lacombe 0 siblings, 2 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-30 22:17 UTC (permalink / raw) To: H. Peter Anvin Cc: Arnaud Lacombe, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On Sat, 2011-07-30 at 15:03 -0700, H. Peter Anvin wrote: > It isn't meaningless for exactly that reason. For example, > "make ARCH=x86 USERARCH=i386" and "make ARCH=x86 USERARCH=x86_64" both > make sense. Similarly, "make ARCH=um USERARCH=i386" is different from > "make ARCH=um USERARCH=x86_64". In that case it's redundant with CONFIG_64BIT, isn't it? -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:17 ` David Woodhouse @ 2011-07-30 22:21 ` H. Peter Anvin 2011-07-30 22:24 ` Arnaud Lacombe 1 sibling, 0 replies; 89+ messages in thread From: H. Peter Anvin @ 2011-07-30 22:21 UTC (permalink / raw) To: David Woodhouse Cc: Arnaud Lacombe, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On 07/30/2011 03:17 PM, David Woodhouse wrote: > On Sat, 2011-07-30 at 15:03 -0700, H. Peter Anvin wrote: >> It isn't meaningless for exactly that reason. For example, >> "make ARCH=x86 USERARCH=i386" and "make ARCH=x86 USERARCH=x86_64" both >> make sense. Similarly, "make ARCH=um USERARCH=i386" is different from >> "make ARCH=um USERARCH=x86_64". > > In that case it's redundant with CONFIG_64BIT, isn't it? Yes, but some architectures have more than one ABI for a particular bitness. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:17 ` David Woodhouse 2011-07-30 22:21 ` H. Peter Anvin @ 2011-07-30 22:24 ` Arnaud Lacombe 2011-07-30 22:34 ` David Woodhouse 1 sibling, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 22:24 UTC (permalink / raw) To: David Woodhouse Cc: H. Peter Anvin, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild Hi, On Sat, Jul 30, 2011 at 6:17 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sat, 2011-07-30 at 15:03 -0700, H. Peter Anvin wrote: >> It isn't meaningless for exactly that reason. For example, >> "make ARCH=x86 USERARCH=i386" and "make ARCH=x86 USERARCH=x86_64" both >> make sense. Similarly, "make ARCH=um USERARCH=i386" is different from >> "make ARCH=um USERARCH=x86_64". > > In that case it's redundant with CONFIG_64BIT, isn't it? > How do you plan to handle x32, if it ever makes it to mainline ? - Arnaud ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:24 ` Arnaud Lacombe @ 2011-07-30 22:34 ` David Woodhouse 2011-07-30 22:39 ` H. Peter Anvin 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-07-30 22:34 UTC (permalink / raw) To: Arnaud Lacombe Cc: H. Peter Anvin, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On Sat, 2011-07-30 at 18:24 -0400, Arnaud Lacombe wrote: > How do you plan to handle x32, if it ever makes it to mainline ? I was pondering that. Surely it would involve porting the kernel itself to x32? And there's never going to be any motivation for that *other* than UML, so I can't really see it happening. What does 'uname -m' give under x32, anyway? -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:34 ` David Woodhouse @ 2011-07-30 22:39 ` H. Peter Anvin 0 siblings, 0 replies; 89+ messages in thread From: H. Peter Anvin @ 2011-07-30 22:39 UTC (permalink / raw) To: David Woodhouse Cc: Arnaud Lacombe, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On 07/30/2011 03:34 PM, David Woodhouse wrote: > On Sat, 2011-07-30 at 18:24 -0400, Arnaud Lacombe wrote: >> How do you plan to handle x32, if it ever makes it to mainline ? > > I was pondering that. Surely it would involve porting the kernel itself > to x32? And there's never going to be any motivation for that *other* > than UML, so I can't really see it happening. > > What does 'uname -m' give under x32, anyway? Right now is gives x86_64, but that should probably be changed before mainlining. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 20:58 ` David Woodhouse 2011-07-30 22:03 ` H. Peter Anvin @ 2011-07-30 22:21 ` Arnaud Lacombe 2011-07-30 22:57 ` David Woodhouse 1 sibling, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-30 22:21 UTC (permalink / raw) To: David Woodhouse Cc: H. Peter Anvin, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild Hi, On Sat, Jul 30, 2011 at 4:58 PM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sat, 2011-07-30 at 11:59 -0700, H. Peter Anvin wrote: >> 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?) > > In the context of a kernel build that's meaningless though. One kernel > can support *many* types of userspace. > > I've just been playing with ARCH=um. It looks like the current state, > even before my patch, is that 'make ARCH=um SUBARCH=x86' is broken. > I fail to see how, to my understanding, something that has not been thought to be used that way can be broken ... > I'll work on a patch to fix that, and then it will be fine when the > default for SUBARCH changes to be "x86". > I still fail to see why you want it that way... You want both ARCH and SUBARCH to be 'x86' ? This starts to be a hell lots of deep changes just to fix i386 build under a fast x86-64 without having to specify ARCH=i386. That job alone can be done a lot easier. - Arnaud > (Another option is to make SUBARCH default to x86 *only* if ARCH!=um, > and still use the legacy SUBARCH values when ARCH=um. But I'm not overly > keen on that approach.) > > Fixing um to work with ARCH=x86 *ought* to be as simple as doing > something like this: > > --- a/arch/um/Makefile > +++ b/arch/um/Makefile > @@ -12,6 +12,15 @@ OS := $(shell uname -s) > # features. > SHELL := /bin/bash > > +# The i386/x86_64 merge hasn't really happened in um-land yet. Fake it. > +ifeq ($(SUBARCH),x86) > +ifeq ($(CONFIG_64BIT),y) > +SUBARCH := x86_64 > +else > +SUBARCH := i386 > +endif > +endif > + > filechk_gen_header = $< > > core-y += $(ARCH_DIR)/kernel/ \ > > .. but that gives me weird behaviour where it just keeps running > silentoldconfig over and over again. > > This patch *does* work, but I'll see if I can make it simpler... > > diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86 > index d31ecf3..576b732 100644 > --- a/arch/um/Kconfig.x86 > +++ b/arch/um/Kconfig.x86 > @@ -19,8 +19,8 @@ config UML_X86 > select GENERIC_FIND_FIRST_BIT > > config 64BIT > - bool > - default SUBARCH = "x86_64" > + bool "64-bit kernel" if SUBARCH = "x86" > + default SUBARCH != "i386" > > config X86_32 > def_bool !64BIT > diff --git a/arch/um/Makefile b/arch/um/Makefile > index fab8121..562c6cb 100644 > --- a/arch/um/Makefile > +++ b/arch/um/Makefile > @@ -12,6 +12,17 @@ OS := $(shell uname -s) > # features. > SHELL := /bin/bash > > +# The i386/x86_64 merge hasn't really happened in um-land yet. Fake it. > +ifeq ($(SUBARCH),x86) > +ifeq ($(CONFIG_64BIT),y) > +UMSUBARCH := x86_64 > +else > +UMSUBARCH := i386 > +endif > +else > +UMSUBARCH := $(SUBARCH) > +endif > + > filechk_gen_header = $< > > core-y += $(ARCH_DIR)/kernel/ \ > @@ -24,11 +35,11 @@ include $(srctree)/$(ARCH_DIR)/Makefile-skas > > SHARED_HEADERS := $(ARCH_DIR)/include/shared > ARCH_INCLUDE := -I$(srctree)/$(SHARED_HEADERS) > -ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH)/shared > +ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(UMSUBARCH)/shared > ifneq ($(KBUILD_SRC),) > ARCH_INCLUDE += -I$(SHARED_HEADERS) > endif > -KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH) > +KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(UMSUBARCH) > > # -Dvmap=kernel_vmap prevents anything from referencing the libpcap.o symbol so > # named - it's a common symbol in libpcap, so we get a binary which crashes. > @@ -38,7 +49,7 @@ KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH) > # > # These apply to USER_CFLAGS to. > > -KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(SUBARCH)\" \ > +KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(UMSUBARCH)\" \ > $(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap \ > -Din6addr_loopback=kernel_in6addr_loopback \ > -Din6addr_any=kernel_in6addr_any > @@ -49,7 +60,7 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\ > $(patsubst -I%,,$(KBUILD_CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \ > $(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 > > -include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH) > +include $(srctree)/$(ARCH_DIR)/Makefile-$(UMSUBARCH) > > #This will adjust *FLAGS accordingly to the platform. > include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS) > @@ -128,8 +139,8 @@ archclean: > > # Generated files > > -$(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s: FORCE > - $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(SUBARCH) $@ > +$(ARCH_DIR)/sys-$(UMSUBARCH)/user-offsets.s: FORCE > + $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(UMSUBARCH) $@ > > define filechk_gen-asm-offsets > (set -e; \ > @@ -144,11 +155,11 @@ define filechk_gen-asm-offsets > echo ""; ) > endef > > -$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s > +$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(UMSUBARCH)/user-offsets.s > $(call filechk,gen-asm-offsets) > > $(SHARED_HEADERS)/kern_constants.h: > $(Q)mkdir -p $(dir $@) > $(Q)echo '#include "../../../../include/generated/asm-offsets.h"' >$@ > > -export SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH > +export SUBARCH UMSUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH > diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386 > index 302cbe5..b66063b 100644 > --- a/arch/um/Makefile-i386 > +++ b/arch/um/Makefile-i386 > @@ -5,22 +5,22 @@ TOP_ADDR := $(CONFIG_TOP_ADDR) > START := 0x8048000 > > LDFLAGS += -m elf_i386 > -ELF_ARCH := $(SUBARCH) > -ELF_FORMAT := elf32-$(SUBARCH) > +ELF_ARCH := $(UMSUBARCH) > +ELF_FORMAT := elf32-$(UMSUBARCH) > OBJCOPYFLAGS := -O binary -R .note -R .comment -S > HEADER_ARCH := x86 > CHECKFLAGS += -D__i386__ > > -ifeq ("$(origin SUBARCH)", "command line") > -ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)") > +#ifeq ("$(origin SUBARCH)", "command line") > +#ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)") > KBUILD_CFLAGS += $(call cc-option,-m32) > KBUILD_AFLAGS += $(call cc-option,-m32) > LINK-y += $(call cc-option,-m32) > UML_OBJCOPYFLAGS += -F $(ELF_FORMAT) > > export LDFLAGS HOSTCFLAGS HOSTLDFLAGS UML_OBJCOPYFLAGS > -endif > -endif > +#endif > +#endif > > # First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y. > include $(srctree)/arch/x86/Makefile_32.cpu > diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile > index b33f4df..c1a2ca3 100644 > --- a/arch/um/os-Linux/Makefile > +++ b/arch/um/os-Linux/Makefile > @@ -5,7 +5,7 @@ > > obj-y = aio.o execvp.o file.o helper.o irq.o main.o mem.o process.o \ > registers.o sigio.o signal.o start_up.o time.o tty.o uaccess.o \ > - umid.o tls.o user_syms.o util.o drivers/ sys-$(SUBARCH)/ skas/ > + umid.o tls.o user_syms.o util.o drivers/ sys-$(UMSUBARCH)/ skas/ > > obj-$(CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA) += elf_aux.o > > > -- > dwmw2 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 22:21 ` Arnaud Lacombe @ 2011-07-30 22:57 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-30 22:57 UTC (permalink / raw) To: Arnaud Lacombe Cc: H. Peter Anvin, Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild On Sat, 2011-07-30 at 18:21 -0400, Arnaud Lacombe wrote: > > I'll work on a patch to fix that, and then it will be fine when the > > default for SUBARCH changes to be "x86". > > > I still fail to see why you want it that way... You want both ARCH and > SUBARCH to be 'x86' ? See the way that SUBARCH is inferred in the Makefile, and then ARCH is set to match it (unless ARCH is set by the user). To change the default setting of ARCH, we actually change the inference of *SUBARCH*. And yes, in the common case they are both the *same*; the SUBARCH variable doesn't really do anything except work as a temporary variable holding the default setting for ARCH. In an ARCH=um build, of course they *are* different, and SUBARCH is actually used for more than that. > This starts to be a hell lots of deep changes just to fix i386 build > under a fast x86-64 without having to specify ARCH=i386. That job > alone can be done a lot easier. It's not just that. It's also about making things work properly as config options — so we can finally complete the merge of arch/i386 and arch/x86_64, which directories we deleted almost four years ago, into the single 'x86' architecture. After a few 'unrelated' cleanups to how $(SUBARCH) is handled, the patch to make SUBARCH=x86 work in um really isn't that intrusive at all; I'll post the sequence shortly. We *could* preserve the legacy inference of SUBARCH={i386,x86_64} *just* for the ARCH=um case, but I think it's better not to. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 15:52 ` Arnaud Lacombe 2011-07-30 16:19 ` David Woodhouse @ 2011-07-31 19:40 ` Arnaud Lacombe 2011-07-31 20:00 ` David Woodhouse 1 sibling, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-31 19:40 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-31 19:40 ` Arnaud Lacombe @ 2011-07-31 20:00 ` David Woodhouse 2011-07-31 20:24 ` Arnaud Lacombe 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-07-31 20:00 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-31 20:00 ` David Woodhouse @ 2011-07-31 20:24 ` Arnaud Lacombe 2011-07-31 20:51 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-31 20:24 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-31 20:24 ` Arnaud Lacombe @ 2011-07-31 20:51 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-31 20:51 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa On Sun, 2011-07-31 at 16:24 -0400, Arnaud Lacombe wrote: > 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}. Ah yes, I'd actually looked at that one yesterday since I saw it referenced from somewhere in the um code that I was looking at. It's not *quite* deadcode yet — remember, we're not talking about *removing* the legacy ARCH=i386 and ARCH=x86_64 yet; just making them no longer the *default*, and making ARCH=x86 the default instead (when on an x86 box). There are three phases, which we've been through for the various other architectures that merged 32 and 64 bit code already: 1. Make ARCH=x86 work. 2. Make ARCH=x86 the default. 3. Remove the legacy ARCH= values. We *thought* we'd fairly much finished #1 in 2007, with commit 208652d6... but evidently there are a couple of things we still need to fix. As I said, thanks for helping to find those. My patch is doing #2, since it seems the best and cleanest way to fix the bug that keeps biting. It's not only "a" fix; it's the *right* thing to do. I'm not touching #3 yet; people are still clinging to the old crap as if the world will end if they have to type 'make CONFIG_64BIT=n oldconfig' instead of 'make ARCH=i386 oldconfig', because the extra few characters will give them RSI and then they'll have to quit their nice computer job and then they'll have to sell their body to make ends meet. Or something like that. But I'm making the CONFIG_64BIT=n thing work anyway :) > 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" OK, I'll go poke at that; it definitely *should* have been working and could be considered 'broken' since 2007. It's part of phase 1. This should probably fix it.... I'll test a bit more and send a real patch. Thanks for pointing it out. diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl index 17e3843..2c5c869 100755 --- a/scripts/checkstack.pl +++ b/scripts/checkstack.pl @@ -59,6 +59,10 @@ my (@stack, $re, $dre, $x, $xs); # 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; + } elsif ($arch eq 'x86') { + # 2f60: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp + $re = qr/^.*[as][du][db] \$(0x$x{1,8}),\%[er]sp$/o; + $dre = qr/^.*[as][du][db] (\%.*),\%[er]sp$/o; } elsif ($arch eq 'ia64') { #e0000000044011fc: 01 0f fc 8c adds r12=-384,r12 $re = qr/.*adds.*r12=-(([0-9]{2}|[3-9])[0-9]{2}),r12/o; -- dwmw2 ^ permalink raw reply related [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse 2011-07-30 1:26 ` Arnaud Lacombe 2011-07-30 15:52 ` Arnaud Lacombe @ 2011-07-31 5:18 ` Arnaud Lacombe 2011-07-31 8:13 ` David Woodhouse 2011-07-31 21:47 ` Arnaud Lacombe 3 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-31 5:18 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, 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 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-31 5:18 ` Arnaud Lacombe @ 2011-07-31 8:13 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-07-31 8:13 UTC (permalink / raw) To: Arnaud Lacombe Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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*. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse ` (2 preceding siblings ...) 2011-07-31 5:18 ` Arnaud Lacombe @ 2011-07-31 21:47 ` Arnaud Lacombe 2011-07-31 21:51 ` Arnaud Lacombe 3 siblings, 1 reply; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-31 21:47 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, 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. > 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 > > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT 2011-07-31 21:47 ` Arnaud Lacombe @ 2011-07-31 21:51 ` Arnaud Lacombe 0 siblings, 0 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-07-31 21:51 UTC (permalink / raw) To: David Woodhouse Cc: Michal Marek, Ted Ts'o, Ingo Molnar, x86, linux-kernel, linux-kbuild, hpa 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 >> >> > ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 20:12 ` David Woodhouse 2011-05-30 22:39 ` [PATCH] Enable 'make CONFIG_FOO=y oldconfig' David Woodhouse @ 2011-05-31 1:44 ` Ted Ts'o 2011-05-31 8:37 ` David Woodhouse 2011-05-31 7:53 ` Ingo Molnar 2 siblings, 1 reply; 89+ messages in thread From: Ted Ts'o @ 2011-05-31 1:44 UTC (permalink / raw) To: David Woodhouse; +Cc: Ingo Molnar, x86, linux-kernel On Mon, May 30, 2011 at 09:12:17PM +0100, David Woodhouse wrote: > > Which is apparently what KCONFIG_ALLCONFIG already does? It doesn't work > for choices, but it's still fine for setting/clearing CONFIG_64BIT. > > We'll want to make it simpler to use - so you really can do something like > make CONFIG_64BIT=n randconfig > make CONFIG_64BIT=n allmodconfig > make CONFIG_64BIT=y CONFIG_SATA_MV=y oldconfig > etc. without having to create a text file. But that's not hard. A simple > implementation might just *make* a file with the options on the command > line and point KCONFIG_ALLCONFIG at it to start with, although there are > probably cleaner ways to implement it. On some architectures, I suspect there will be a dozen or more CONFIG that have to be a certain way in order for the machine to boot. Are you really going to want to put them all on the command line? I suppose the question is whether people are using randconfig for simple compile testing, or just for something that they actually try to boot, either on real hardware or on a KVM system. I was under the impression Ingo and others actually tried to boot their randconfig kernels, correct? - Ted ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 1:44 ` [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' Ted Ts'o @ 2011-05-31 8:37 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-31 8:37 UTC (permalink / raw) To: Ted Ts'o; +Cc: Ingo Molnar, x86, linux-kernel On Mon, 2011-05-30 at 21:44 -0400, Ted Ts'o wrote: > On some architectures, I suspect there will be a dozen or more CONFIG > that have to be a certain way in order for the machine to boot. Are > you really going to want to put them all on the command line? No. This is just a convenience for setting/clearing a few options (although "make `cat my-config-overrides` oldconfig" would also work if you have a bunch of them, I suppose.) Remember, we're having this discussion because Ingo needs a command-line method to override *just* CONFIG_64BIT. Nothing more. That's all that's really holding us back from finally completing the i386/x86_64 -> x86 merge. > I suppose the question is whether people are using randconfig for > simple compile testing, or just for something that they actually try > to boot, either on real hardware or on a KVM system. I was under the > impression Ingo and others actually tried to boot their randconfig > kernels, correct? I *sincerely* hope that isn't the reason for this requirement. If they *are* actually booting these kernels, then they'll need more than just one setting to be hard-coded, as you correctly observe. That would mean that they must already be using KCONFIG_ALLCONFIG, or an 'all.config' file which overrides the settings they need for their storage hardware, for CGROUPS to match their userspace if they have systemd, etc. And that, in turn, would mean that all this whining about needing an easier way to set CONFIG_64BIT is *pure* nonsense, because they could have just added it to their existing list. So no, allowing CONFIG_FOO= on the make command line was not intended as a way to set options in bulk. We have *other* ways of doing that, which do take them from a file. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 20:12 ` David Woodhouse 2011-05-30 22:39 ` [PATCH] Enable 'make CONFIG_FOO=y oldconfig' David Woodhouse 2011-05-31 1:44 ` [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' Ted Ts'o @ 2011-05-31 7:53 ` Ingo Molnar 2011-05-31 8:55 ` David Woodhouse 2 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 7:53 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap * David Woodhouse <dwmw2@infradead.org> wrote: > And then this legacy trick of using the obsolete $ARCH settings to > override the setting of CONFIG_64BIT can be deprecated. Sigh, nope. The two legacies we have should simply be turned into trivial aliases that map to the newfangled CONFIG_*=y way of doing things. I'll always prefer typing: make ARCH=x86_64 ... To: make ARCH=x86 CONFIG_64BIT=y ... And others have expressed that in this thread too. Really, guys, please stop breaking existing tools! There is no problem to solve here, having ARCH=i386 and ARCH=x86_64 around does not hurt anyone, is well established and actively helps people so what's your problem? I'll be happy to learn the new methods and will happily add them to the toolbox of existing methods. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 7:53 ` Ingo Molnar @ 2011-05-31 8:55 ` David Woodhouse 2011-05-31 10:41 ` Ingo Molnar 2011-05-31 12:12 ` Ted Ts'o 0 siblings, 2 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-31 8:55 UTC (permalink / raw) To: Ingo Molnar Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: > I'll always prefer typing: > make ARCH=x86_64 ... > To: > make ARCH=x86 CONFIG_64BIT=y ... You're not building on an x86 box? I always suspected you had some alien technology! Does it run Linux? Why else would you need to specify ARCH=x86 on the latter command line? -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 8:55 ` David Woodhouse @ 2011-05-31 10:41 ` Ingo Molnar 2011-05-31 11:43 ` David Woodhouse 2011-05-31 12:12 ` Ted Ts'o 1 sibling, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 10:41 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap * David Woodhouse <dwmw2@infradead.org> wrote: > On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: > > I'll always prefer typing: > > make ARCH=x86_64 ... > > To: > > make ARCH=x86 CONFIG_64BIT=y ... > > Why else would you need to specify ARCH=x86 on the latter command line? Note that if we are consistent and implement the logical extension of your CONFIG_64BIT 'fix' then we could pick up the target architecture from the .config as well and not use the host architecture. The very same arguments apply: the user provided an ARCH=arm .config, why does 'make oldconfig' switch it to x86_64 automatically? Also, i prefer to type out the architecture due to: | [ Btw., 'override the architecture' usecase is not just theoretical: | i sometimes use this form to convert existing .config's *between* | architectures, not just from 32-bit to 64-bit. So if i get an ARM | bugreport that gives me the appearance of a core kernel bug i will | often start by converting that to an x86 .config via 'make | ARCH=x86_64 oldconfig'. ] But even if we leave out the 'ARCH=x86' portion, which ones are the two shortest commands to type, in your opinion: make ARCH=i386 make ARCH=x86_64 make CONFIG_64BIT=y ? > You're not building on an x86 box? I always suspected you had some > alien technology! Does it run Linux? Could you please stop with this borderline taunting tone? You've been wrong so many times in this thread that i think toning down some of your shouting in favor of a bit more listening would be well advised ... Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 10:41 ` Ingo Molnar @ 2011-05-31 11:43 ` David Woodhouse 2011-05-31 12:45 ` Ingo Molnar 2011-05-31 14:14 ` Geert Uytterhoeven 0 siblings, 2 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-31 11:43 UTC (permalink / raw) To: Ingo Molnar Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, 2011-05-31 at 12:41 +0200, Ingo Molnar wrote: > * David Woodhouse <dwmw2@infradead.org> wrote: > > > On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: > > > I'll always prefer typing: > > > make ARCH=x86_64 ... > > > To: > > > make ARCH=x86 CONFIG_64BIT=y ... > > > > Why else would you need to specify ARCH=x86 on the latter command line? > > Note that if we are consistent and implement the logical extension of > your CONFIG_64BIT 'fix' then we could pick up the target architecture > from the .config as well and not use the host architecture. It would be interesting, perhaps, to make the architecture a config option. Distinctly non-trivial, though. I think it's been discussed before. On the other hand, CONFIG_64BIT *is* a config option, and has been ever since we merged the 32-bit and 64-bit support into arch/x86. > The very same arguments apply: the user provided an ARCH=arm .config, > why does 'make oldconfig' switch it to x86_64 automatically? Yes, it's "automatic" because the architecture is *not* a config option. But yes, perhaps it would be nice if it *was*. > Also, i prefer to type out the architecture due to: > | ...So if i get an ARM > | bugreport that gives me the appearance of a core kernel bug i will > | often start by converting that to an x86 .config via 'make > | ARCH=x86_64 oldconfig'. ] So first you point out that it's automatic, and then you still specify it manually? > But even if we leave out the 'ARCH=x86' portion, which ones are the > two shortest commands to type, in your opinion: > > make ARCH=i386 > make ARCH=x86_64 > make CONFIG_64BIT=y > > ? > > > You're not building on an x86 box? I always suspected you had some > > alien technology! Does it run Linux? > > Could you please stop with this borderline taunting tone? > > You've been wrong so many times in this thread that i think toning > down some of your shouting in favor of a bit more listening would be > well advised ... No, Ingo. I haven't been wrong. I don't think either of us is *wrong*. Let's review a little... - You like to use 'ARCH=i386' and 'ARCH=x86_64' as a convenient shortcut to override the CONFIG_64BIT option. - I *don't* like it when the CONFIG_64BIT option is silently overridden according to the host architecture. - I posted a patch making ARCH=x86 the default 'inferred' architecture, so that both of our desires are met. - I was uncomfortable with keeping the legacy 'ARCH=i386' and 'ARCH=x86_64' settings around now that arch/i386 and arch/x86_64 are actually dead. I observed that while you have a valid need to set CONFIG_64BIT, that's a trick that actually works *only* on x86 because we haven't finished the merge and removed the dregs of the old architectures, and it works *only* for CONFIG_64BIT. It seems *unclean*. It doesn't work on anything *else* you might need to set to test 'core' functionality, such as CONFIG_SMP, and not on anything you might need to set to actually boot your kernel on a test box, such as CONFIG_SATA_MV, and not on anything else you might need to be compatible with the userspace on your test box, such as CONFIG_CGROUPS if you have a Fedora 15 userspace with systemd. And it doesn't *even* work for CONFIG_64BIT on any platforms other than x86, for example powerpc where the legacy ARCH=ppc and ARCH=ppc64 settings actually got removed when the merge was completed. - I posted a patch which gives a more generic way to set config options from the make command line, which satisfies *all* the above requirements (except that it doesn't auto-enable dependencies, as observed). To me, it seems much cleaner and nicer. I observed that the legacy ARCH= trick *can* now be deprecated, but didn't actually post a patch which *does* deprecate or remove it. - You objected, because you would have to type three more letters to enable CONFIG_64BIT, and a whole *five* more to disable it. Except you lied a bit in your message, adding a pointless 'ARCH=x86' to make it look like it was even *more* extra typing, and the world would actually end. Did I miss something? Aside from you adding 'ARCH=x86' to the example in your latest message to make it look like I'm going to contribute more to your RSI to I actually am, I don't think anyone was really *wrong*. It's just a matter of opinion. I see this use of ARCH=i386 as a limited legacy hack, and implemented something which allows us to do that and much more in a *clean* and generic fashion. I happen to believe that even if it means we have to type a couple of extra characters when the command isn't in our command history already, it's worth it to have a clean generic interface instead of a legacy hack. You, evidently, have a different opinion. That is your right. I think you're being *silly*, but I don't think you're *wrong*. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 11:43 ` David Woodhouse @ 2011-05-31 12:45 ` Ingo Molnar 2011-05-31 13:44 ` David Woodhouse 2011-05-31 14:14 ` Geert Uytterhoeven 1 sibling, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 12:45 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap * David Woodhouse <dwmw2@infradead.org> wrote: > > Also, i prefer to type out the architecture due to: > > | ...So if i get an ARM > > | bugreport that gives me the appearance of a core kernel bug i will > > | often start by converting that to an x86 .config via 'make > > | ARCH=x86_64 oldconfig'. ] > > So first you point out that it's automatic, and then you still specify > it manually? Currently it's not automatic so i prefer to type it out. > > Could you please stop with this borderline taunting tone? > > > > You've been wrong so many times in this thread that i think > > toning down some of your shouting in favor of a bit more > > listening would be well advised ... > > No, Ingo. I haven't been wrong. [...] Of course you've been wrong more than once - and you are now forcing me to count them. Lets start with your very first mail: Message-ID: <1306707270.2029.377.camel@i7.infradead.org> "Ingo's objection that he didn't actually want 'make randconfig' to give him a random config" You now know that your claim was wrong, right? :) " I still maintain that if you actually want a non-random 'randconfig', perhaps because you want it to be bootable on certain test machines, then you're going to need to hard-code a whole lot more than *one* config option — and you'd be better off coming up with a proper mechanism to do *that* instead of preserving the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack to achieve it only for the CONFIG_X86_32 option. " Here you clearly didn't know about KCONFIG_CONFIG, so you incorrectly delegated ARCH=i386 / ARCH=x86_64 to a 'dirty hack'. Message-ID: <1306745835.2029.389.camel@i7.infradead.org> "I believe that this 'filtered randconfig' behaviour is now fairly much the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'." You are wrong again - it isnt, as me and others pointed it out. " Other than that, we ought to finally be able to 'complete' the merge of 32-bit and 64-bit support into ARCH=x86, and remove the last traces of the obsolete ARCH={i386,x86_64} settings completely? " And you are wrong again - many people rely on it and it's useful so it's not "obsolete". " And as I said, it's still an incomplete solution if you actually want a 'filtered randconfig' to do anything *useful*. " Wrong again: you miss KCONFIG_CONFIG. Message-ID: <1306750004.2029.413.camel@i7.infradead.org> " No, ARCH= is just for cross-compiling. If you're *on* an ARM or MIPS box, you don't need the ARCH= bit. " That's wrong again: ARCH= can be used to just extract a config variant of an architecture (with no intention to cross-build - this will even work without *any* crosscompilers installed), *and* it can also be used for consistency if you use mixed environments where you might not necessarily always be aware of exactly which box you are on. etc. etc. How many times do you need to be proven wrong before you admit having been at least slightly wrong, hm? Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 12:45 ` Ingo Molnar @ 2011-05-31 13:44 ` David Woodhouse 2011-05-31 13:56 ` Ingo Molnar 0 siblings, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-31 13:44 UTC (permalink / raw) To: Ingo Molnar Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, 2011-05-31 at 14:45 +0200, Ingo Molnar wrote: > * David Woodhouse <dwmw2@infradead.org> wrote: > > > > Also, i prefer to type out the architecture due to: > > > | ...So if i get an ARM > > > | bugreport that gives me the appearance of a core kernel bug i will > > > | often start by converting that to an x86 .config via 'make > > > | ARCH=x86_64 oldconfig'. ] > > > > So first you point out that it's automatic, and then you still specify > > it manually? > > Currently it's not automatic so i prefer to type it out. No, you were right the first time. It *is* automatic. If you take an ARM config and on your x86 box you 'make oldconfig', it *will* be converted. There's absolutely no need to set ARCH= on the command line. > > > Could you please stop with this borderline taunting tone? > > > > > > You've been wrong so many times in this thread that i think > > > toning down some of your shouting in favor of a bit more > > > listening would be well advised ... > > > > No, Ingo. I haven't been wrong. [...] > > Of course you've been wrong more than once - and you are now forcing > me to count them. > > Lets start with your very first mail: > > Message-ID: <1306707270.2029.377.camel@i7.infradead.org> > > "Ingo's objection that he didn't actually want 'make > randconfig' to give him a random config" > > You now know that your claim was wrong, right? :) Absolutely not. To quote your reply: "...the problem with your patch was that your patch actually *broke* existing filtered-randconfig behavior, for example trying to get a 64-bit randconfig: "make ARCH=x86_64 randconfig "... will today produce a 64-bit randconfig while with your old change applied it produced a 32-bit randconfig 50% of the time." In the above quote, you *are* objecting that the value of CONFIG_64BIT in the resulting config is *random*. You *are* objecting that it made 'randconfig' actually random. We have $KCONFIG_ALLCONFIG/allrandom.conf/all.config which allow you to override *various* settings in 'randconfig' so that they aren't randomised, but you either weren't aware of that or you didn't want to use it for some reason. I wasn't aware of it at the time either, so didn't point it out to you. > " I still maintain that if you actually want a non-random > 'randconfig', perhaps because you want it to be bootable on > certain test machines, then you're going to need to hard-code a > whole lot more than *one* config option — and you'd be better > off coming up with a proper mechanism to do *that* instead of > preserving the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack > to achieve it only for the CONFIG_X86_32 option. " > > Here you clearly didn't know about KCONFIG_CONFIG, so you incorrectly > delegated ARCH=i386 / ARCH=x86_64 to a 'dirty hack'. You have done nothing to show that using ARCH=i386/ARCH=x86_64 to override the value of CONFIG_64BIT should not be considered a 'dirty hack'. I've provided a clean, generic way to set config symbols from the command line, and now it is just just a dirty hack but an *obsolete* dirty hack. I'm not sure how KCONFIG_CONFIG relates to that. Even if you mean KCONFIG_ALLCONFIG, that just means that there was *already* a clean and generic way to do it, so you're calling me wrong because I should actually have said: "We *already* have a proper mechanism to do that instead of preserving the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack..." ? > Message-ID: <1306745835.2029.389.camel@i7.infradead.org> > > "I believe that this 'filtered randconfig' behaviour is now fairly much > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'." > > You are wrong again - it isnt, as me and others pointed it out. Not *so* wrong that all those other use cases couldn't be addressed in the same, simple patch to allow CONFIG_FOO on the 'make' command line. But yes, I agree that there were other ways in which people wanted to override CONFIG_64BIT on the command line, that I did not list. Some of them were even not covered by the existing KCONFIG_ALLCONFIG facility. > " Other than that, we ought to finally be able to 'complete' the > merge of 32-bit and 64-bit support into ARCH=x86, and remove > the last traces of the obsolete ARCH={i386,x86_64} settings > completely? " > > And you are wrong again - many people rely on it and it's useful so > it's not "obsolete". I strongly suspect that most people who set ARCH=i386 and ARCH=x86_64 on the command line are only doing so to work around the original bug that I set out to fix, where a simple 'make' would ignore your setting of CONFIG_64BIT in the existing .config, and override it to match the build host. The arch/i386 and arch/x86_64 directories are dead; the ARCH= settings to match them are obsolete — especially now that we have a cleaner way for people to override the setting of CONFIG_64BIT on the command line. > " And as I said, it's still an incomplete solution if you > actually want a 'filtered randconfig' to do anything *useful*. > " > > Wrong again: you miss KCONFIG_CONFIG. I do think you mean KCONFIG_ALLCONFIG? So in this case you're saying I'm wrong because I should have called the ARCH=x86_64 hack an incomplete *and* *redundant* solution, rather than just 'incomplete'? > Message-ID: <1306750004.2029.413.camel@i7.infradead.org> > > " No, ARCH= is just for cross-compiling. If you're *on* an ARM or > MIPS box, you don't need the ARCH= bit. " > > That's wrong again: ARCH= can be used to just extract a config > variant of an architecture (with no intention to cross-build - this > will even work without *any* crosscompilers installed), Now you're just being silly. Yes, I was lazy and said 'cross-compiling' when I could have said "cross-compiling or cross-configuring or cross-header-installing or cross-module-installing or cross-linking or ....". But the point I was making was exactly the same. So yes, I was slightly wrong once when I underestimated the amount of 'valid' uses there still were for using 'ARCH=i386' or 'ARCH=x86_64' on the command line. But as I said, not so wrong that we couldn't satisfy *all* those with the same simple patch. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 13:44 ` David Woodhouse @ 2011-05-31 13:56 ` Ingo Molnar 2011-05-31 14:31 ` David Woodhouse 0 siblings, 1 reply; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 13:56 UTC (permalink / raw) To: David Woodhouse Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap * David Woodhouse <dwmw2@infradead.org> wrote: > On Tue, 2011-05-31 at 14:45 +0200, Ingo Molnar wrote: > > * David Woodhouse <dwmw2@infradead.org> wrote: > > > > > > Also, i prefer to type out the architecture due to: > > > > | ...So if i get an ARM > > > > | bugreport that gives me the appearance of a core kernel bug i will > > > > | often start by converting that to an x86 .config via 'make > > > > | ARCH=x86_64 oldconfig'. ] > > > > > > So first you point out that it's automatic, and then you still specify > > > it manually? > > > > Currently it's not automatic so i prefer to type it out. > > No, you were right the first time. It *is* automatic. The architecture *inside* the .config is not inherited automatically but overriden by the host architecture, so due to this assymetry i prefer to use explicit ARCH=xxx lines whenever i deal with configs. > > "I believe that this 'filtered randconfig' behaviour is now fairly much > > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'." > > > > You are wrong again - it isnt, as me and others pointed it out. > > Not *so* wrong that all those other use cases couldn't be addressed > in the same, simple patch to allow CONFIG_FOO on the 'make' command > line. So "partially wrong" is not wrong? Indeed, if defined that way then i agree that you must almost never be wrong ;-) Really, i have little interest in continuing the 'who was wrong' angle of this discussion - i think people can read and i think people have made it rather clear what they are using and why, and what they'd like to see continue work, which requirements i'll try to apply to related patches you send. The last version of your patch looked good at first sight, except the changelog. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 13:56 ` Ingo Molnar @ 2011-05-31 14:31 ` David Woodhouse 0 siblings, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-31 14:31 UTC (permalink / raw) To: Ingo Molnar Cc: Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, 2011-05-31 at 15:56 +0200, Ingo Molnar wrote: > The architecture *inside* the .config is not inherited automatically > but overriden by the host architecture, so due to this assymetry i > prefer to use explicit ARCH=xxx lines whenever i deal with configs. Yes. That is why you *don't* need to run 'make ARCH=foo oldconfig' to convert it to your native architecture; just 'make oldconfig' will work fine. I appreciate that you *like* to type it out anyway, and that's fine. Not entirely sure how it's relevant to the rest of the discussion, except to make you look a little sillier when you complain about the horrendous amount of extra typing it is to use the new clean generic 'CONFIG_FOO=' interface instead of using the legacy ARCH values to set CONFIG_64BIT. > > > "I believe that this 'filtered randconfig' behaviour is now fairly much > > > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'." > > > > > > You are wrong again - it isnt, as me and others pointed it out. > > > > Not *so* wrong that all those other use cases couldn't be addressed > > in the same, simple patch to allow CONFIG_FOO on the 'make' command > > line. > > So "partially wrong" is not wrong? Indeed, if defined that way then i > agree that you must almost never be wrong ;-) I said "this is fairly much the only remaining use", and some more use cases were pointed out that were almost identical to the ones we'd already discussed, and that were handled by the same patch. Gosh, how wrong I was! You should shoot me now! > Really, i have little interest in continuing the 'who was wrong' > angle of this discussion Very sensible. Hopefully we can agree that: - The only thing that ARCH=i386 and ARCH=x86_64 now do, since the merge into arch/x86, is override the setting of CONFIG_64BIT. - Until now, that override has also happened even when the user *didn't* pass any ARCH= on the command line. Instead of using the value of CONFIG_64BIT from the .config, it would automatically get changed to match the host! - This meant that people were forced to set ARCH= on the command line, just to make the build system honour the existing .config file. - The patch I submitted will make that override happen *only* when ARCH is explicitly specified as i386 or x86_64, which you use. It will *stop* it from happening when no ARCH= is specified. Yay! - The second patch I submitted will allow you to set *any* visible config symbol from the command line, which will be useful in many ways in addition to letting you set CONFIG_64BIT. - Now that you can set CONFIG_64BIT on the command line, the only remaining use of ARCH=i386 and ARCH=x86_64 is redundant. Note that I've carefully avoided saying 'obsolete'. Only 'redundant', which I'm sure you won't disagree with. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 11:43 ` David Woodhouse 2011-05-31 12:45 ` Ingo Molnar @ 2011-05-31 14:14 ` Geert Uytterhoeven 1 sibling, 0 replies; 89+ messages in thread From: Geert Uytterhoeven @ 2011-05-31 14:14 UTC (permalink / raw) To: David Woodhouse Cc: Ingo Molnar, Ted Ts'o, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, May 31, 2011 at 13:43, David Woodhouse <dwmw2@infradead.org> wrote: > On Tue, 2011-05-31 at 12:41 +0200, Ingo Molnar wrote: >> * David Woodhouse <dwmw2@infradead.org> wrote: >> > On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: >> > > I'll always prefer typing: >> > > make ARCH=x86_64 ... >> > > To: >> > > make ARCH=x86 CONFIG_64BIT=y ... >> > >> > Why else would you need to specify ARCH=x86 on the latter command line? >> >> Note that if we are consistent and implement the logical extension of >> your CONFIG_64BIT 'fix' then we could pick up the target architecture >> from the .config as well and not use the host architecture. > > It would be interesting, perhaps, to make the architecture a config > option. Distinctly non-trivial, though. I think it's been discussed > before. IIRC, that's one of the goals on the kbuild plan. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 8:55 ` David Woodhouse 2011-05-31 10:41 ` Ingo Molnar @ 2011-05-31 12:12 ` Ted Ts'o 2011-05-31 12:32 ` David Woodhouse 2011-05-31 12:50 ` Ingo Molnar 1 sibling, 2 replies; 89+ messages in thread From: Ted Ts'o @ 2011-05-31 12:12 UTC (permalink / raw) To: David Woodhouse Cc: Ingo Molnar, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, May 31, 2011 at 09:55:47AM +0100, David Woodhouse wrote: > On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: > > I'll always prefer typing: > > make ARCH=x86_64 ... > > To: > > make ARCH=x86 CONFIG_64BIT=y ... > > You're not building on an x86 box? I always suspected you had some alien > technology! Does it run Linux? > > Why else would you need to specify ARCH=x86 on the latter command line? I don't know why Ingo needs ARCH=x86 on the command line, but I regularly type "make ARCH=i386" when building 32-bit kernels on a 64-bit system, and my scripts use "make ARCH=x86_64" when building 64-bit kernels (just in case I happen to have booted a 32-bit kernel). - Ted ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 12:12 ` Ted Ts'o @ 2011-05-31 12:32 ` David Woodhouse 2011-05-31 12:50 ` Ingo Molnar 1 sibling, 0 replies; 89+ messages in thread From: David Woodhouse @ 2011-05-31 12:32 UTC (permalink / raw) To: Ted Ts'o Cc: Ingo Molnar, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap On Tue, 2011-05-31 at 08:12 -0400, Ted Ts'o wrote: > I don't know why Ingo needs ARCH=x86 on the command line, but I > regularly type "make ARCH=i386" when building 32-bit kernels on a > 64-bit system, and my scripts use "make ARCH=x86_64" when building > 64-bit kernels (just in case I happen to have booted a 32-bit > kernel). Yes. That's because of the problem described in $SUBJECT. Historically, the setting of CONFIG_64BIT in your .config file was just completely ignored in most cases. If you specified ARCH=i386 or ARCH=x86_64 on the command line it would be set accordingly, but if you *didn't* set it explicitly then the build system would *still* ignore what's in the existing .config, and just override it to match the host! The *only* time that the .config would be honoured was if you explicitly added ARCH=x86 to the command line. That's why your scripts grew these hacks, presumably. -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-31 12:12 ` Ted Ts'o 2011-05-31 12:32 ` David Woodhouse @ 2011-05-31 12:50 ` Ingo Molnar 1 sibling, 0 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-31 12:50 UTC (permalink / raw) To: Ted Ts'o, David Woodhouse, x86, linux-kernel, Alexey Dobriyan, Randy Dunlap * Ted Ts'o <tytso@mit.edu> wrote: > On Tue, May 31, 2011 at 09:55:47AM +0100, David Woodhouse wrote: > > On Tue, 2011-05-31 at 09:53 +0200, Ingo Molnar wrote: > > > I'll always prefer typing: > > > make ARCH=x86_64 ... > > > To: > > > make ARCH=x86 CONFIG_64BIT=y ... > > > > You're not building on an x86 box? I always suspected you had some alien > > technology! Does it run Linux? > > > > Why else would you need to specify ARCH=x86 on the latter command line? > > I don't know why Ingo needs ARCH=x86 on the command line, [...] I replied to the hypothetical scenario where CONFIG_64BIT=y works and ARCH=x86_64 and ARCH=i386 are deprecated because they are supposedly a 'dirty hack' and 'obsolete'. (David's words, not mine) I vehemently disagree with the deprecation of ARCH=i386 and ARCH=x86_64 and with the characterisation as well. > [...] but I regularly type "make ARCH=i386" when building 32-bit > kernels on a 64-bit system, and my scripts use "make ARCH=x86_64" > when building 64-bit kernels (just in case I happen to have booted > a 32-bit kernel). Ditto here. They are not just useful but logical as well. This is what the whole thread is about: i want this behavior to be *preserved*. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 10:58 ` Ingo Molnar 2011-05-30 11:04 ` Theodore Tso @ 2011-05-30 11:06 ` David Woodhouse 2011-05-30 11:34 ` Ingo Molnar 1 sibling, 1 reply; 89+ messages in thread From: David Woodhouse @ 2011-05-30 11:06 UTC (permalink / raw) To: Ingo Molnar; +Cc: Theodore Tso, x86, linux-kernel On Mon, 2011-05-30 at 12:58 +0200, Ingo Molnar wrote: > > * Theodore Tso <tytso@MIT.EDU> wrote: > > > I'd think that "make ARCH=x86_64 oldconfig" > > > > ... where the old configuration contained CONFIG_X86_32 > > should trigger a warning, if not an outright error that > > stops the build.... > > That would be a rather sad regression for me: i use that command > regularly to transform .configs that came in bugreports into a config > suitable for a testbox that has a different bitness userspace > installed. And if it has a different SCSI or ATA controller? Then you need something like: 'make CONFIG_SATA_MV=y oldconfig' to make your config actually useful. Which only goes to reinforce my point that CONFIG_64BIT *isn't* that special. Yes, we should fix the tools so that it's easy to *fix* certain settings when running randconfig/oldconfig/all*config. That addresses *all* your examples that you posted in a separate mail, doesn't it? Without being a dirty hack which only works for *one* setting (CONFIG_64BIT), and only works on *one* architecture (there is no equivalent ARCH= hack for setting CONFIG_64BIT on powerpc/mips/sparc/sh/parisc). -- dwmw2 ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:06 ` David Woodhouse @ 2011-05-30 11:34 ` Ingo Molnar 0 siblings, 0 replies; 89+ messages in thread From: Ingo Molnar @ 2011-05-30 11:34 UTC (permalink / raw) To: David Woodhouse; +Cc: Theodore Tso, x86, linux-kernel * David Woodhouse <dwmw2@infradead.org> wrote: > On Mon, 2011-05-30 at 12:58 +0200, Ingo Molnar wrote: > > > > * Theodore Tso <tytso@MIT.EDU> wrote: > > > > > I'd think that "make ARCH=x86_64 oldconfig" > > > > > > ... where the old configuration contained CONFIG_X86_32 > > > should trigger a warning, if not an outright error that > > > stops the build.... > > > > That would be a rather sad regression for me: i use that command > > regularly to transform .configs that came in bugreports into a config > > suitable for a testbox that has a different bitness userspace > > installed. > > And if it has a different SCSI or ATA controller? Then you need > something like: > > 'make CONFIG_SATA_MV=y oldconfig' > > to make your config actually useful. When it wont boot straight away (often it does) i use a Kconfig-needed set of minimal set of configs that enables the minimal hardware environment. But bitness is not really a 'hardware environment' thing - it's a CPU mode thing that i want to match to 32-bit or 64-bit user-space, depending on which one i want to boot. So bitness *is* special, even if we ignored all the well-established workflows where people became to rely on (and appreciate) what ARCH=i386 and ARCH=x86_64 specifiers give us today and which ARCH=x86 does not replace in an equivalent fashion. Thanks, Ingo ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 8:57 ` David Woodhouse 2011-05-30 9:15 ` Ingo Molnar 2011-05-30 10:42 ` [PATCH] Fix corruption of CONFIG_X86_32 " Ingo Molnar @ 2011-05-30 11:05 ` Arnd Bergmann 2011-05-30 17:27 ` Randy Dunlap 2 siblings, 1 reply; 89+ messages in thread From: Arnd Bergmann @ 2011-05-30 11:05 UTC (permalink / raw) To: David Woodhouse, John Stultz; +Cc: Ingo Molnar, x86, linux-kernel On Monday 30 May 2011, David Woodhouse wrote: > And as I said, it's still an incomplete solution if you actually want a > 'filtered randconfig' to do anything *useful*. You'd be much better off > implementing a real filtered randconfig that allows you to give a list > of hard-coded options, rather than relying on a dirty hack that only > actually sets one option of the many that you might need to > 'hard-code' if you actually wanted a useful build. I'm actually looking for a way to do filtered randconfig (and all{yes,mod,no}config) for ARM, so hopefully we can come up with something useful. Our problem today is that we have not just two but dozens of incompatible platforms, and with randconfig every 'choice' statements still just gets its default, which makes randconfig builds fairly useless. What I'd like to see is one or both of these two behaviors: * Take a defconfig file (with the new format that only sets non-default options), and keep everything in there but apply the rand/no/yes/mod-config to all other symbols. * Randomize all settings, including choice statements. Arnd ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 11:05 ` Arnd Bergmann @ 2011-05-30 17:27 ` Randy Dunlap 2011-05-30 18:40 ` Arnd Bergmann 0 siblings, 1 reply; 89+ messages in thread From: Randy Dunlap @ 2011-05-30 17:27 UTC (permalink / raw) To: Arnd Bergmann Cc: David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011 13:05:58 +0200 Arnd Bergmann wrote: > On Monday 30 May 2011, David Woodhouse wrote: > > And as I said, it's still an incomplete solution if you actually want a > > 'filtered randconfig' to do anything *useful*. You'd be much better off > > implementing a real filtered randconfig that allows you to give a list > > of hard-coded options, rather than relying on a dirty hack that only > > actually sets one option of the many that you might need to > > 'hard-code' if you actually wanted a useful build. > > I'm actually looking for a way to do filtered randconfig (and > all{yes,mod,no}config) for ARM, so hopefully we can come up with > something useful. > > Our problem today is that we have not just two but dozens of > incompatible platforms, and with randconfig every 'choice' > statements still just gets its default, which makes randconfig > builds fairly useless. > > What I'd like to see is one or both of these two behaviors: > > * Take a defconfig file (with the new format that only sets > non-default options), and keep everything in there but > apply the rand/no/yes/mod-config to all other symbols. Ingo recently wrote: | When it wont boot straight away (often it does) i use a | Kconfig-needed set of minimal set of configs that enables the minimal | hardware environment. which I believe is the same method that is documented in Documentation/kbuild/kconfig.txt, subject "KCONFIG_ALLCONFIG": (partial text) This enables you to create "miniature" config (miniconfig) or custom config files containing just the config symbols that you are interested in. Then the kernel config system generates the full .config file, including symbols of your miniconfig file. This 'KCONFIG_ALLCONFIG' file is a config file which contains (usually a subset of all) preset config symbols. These variable settings are still subject to normal dependency checks. > * Randomize all settings, including choice statements. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 17:27 ` Randy Dunlap @ 2011-05-30 18:40 ` Arnd Bergmann 2011-05-30 20:01 ` Randy Dunlap 2011-05-30 20:30 ` Arnaud Lacombe 0 siblings, 2 replies; 89+ messages in thread From: Arnd Bergmann @ 2011-05-30 18:40 UTC (permalink / raw) To: Randy Dunlap; +Cc: David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel On Monday 30 May 2011 19:27:31 Randy Dunlap wrote: > On Mon, 30 May 2011 13:05:58 +0200 Arnd Bergmann wrote: > > Ingo recently wrote: > | When it wont boot straight away (often it does) i use a > | Kconfig-needed set of minimal set of configs that enables the minimal > | hardware environment. > > which I believe is the same method that is documented in > Documentation/kbuild/kconfig.txt, subject "KCONFIG_ALLCONFIG": (partial text) > > This enables you to create "miniature" config (miniconfig) or custom > config files containing just the config symbols that you are interested > in. Then the kernel config system generates the full .config file, > including symbols of your miniconfig file. > > This 'KCONFIG_ALLCONFIG' file is a config file which contains > (usually a subset of all) preset config symbols. These variable > settings are still subject to normal dependency checks. > Very nice, I didn't know about it. Unfortunately, this seems to suffer from the same problem as the generic "randconfig" -- it ignores all "choice" statements and just uses the default: Try for instance KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make \ O=obj-allmod/ allnoconfig ARCH=arm This is supposed to set CONFIG_ARCH_OMAP, but it instead chooses CONFIG_ARCH_VERSATILE, which means it's still useless for me. Arnd ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 18:40 ` Arnd Bergmann @ 2011-05-30 20:01 ` Randy Dunlap 2011-05-30 20:30 ` Arnaud Lacombe 1 sibling, 0 replies; 89+ messages in thread From: Randy Dunlap @ 2011-05-30 20:01 UTC (permalink / raw) To: Arnd Bergmann, linux-kbuild Cc: David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011 20:40:55 +0200 Arnd Bergmann wrote: > On Monday 30 May 2011 19:27:31 Randy Dunlap wrote: > > On Mon, 30 May 2011 13:05:58 +0200 Arnd Bergmann wrote: > > > > Ingo recently wrote: > > | When it wont boot straight away (often it does) i use a > > | Kconfig-needed set of minimal set of configs that enables the minimal > > | hardware environment. > > > > which I believe is the same method that is documented in > > Documentation/kbuild/kconfig.txt, subject "KCONFIG_ALLCONFIG": (partial text) > > > > This enables you to create "miniature" config (miniconfig) or custom > > config files containing just the config symbols that you are interested > > in. Then the kernel config system generates the full .config file, > > including symbols of your miniconfig file. > > > > This 'KCONFIG_ALLCONFIG' file is a config file which contains > > (usually a subset of all) preset config symbols. These variable > > settings are still subject to normal dependency checks. > > > > Very nice, I didn't know about it. Unfortunately, this seems to > suffer from the same problem as the generic "randconfig" -- it > ignores all "choice" statements and just uses the default: > > Try for instance > > KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make \ > O=obj-allmod/ allnoconfig ARCH=arm > > This is supposed to set CONFIG_ARCH_OMAP, but it instead chooses > CONFIG_ARCH_VERSATILE, which means it's still useless for me. baa humbug. dear linux-kbuild, can "choice" choices be made random during "make randconfig", please? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 18:40 ` Arnd Bergmann 2011-05-30 20:01 ` Randy Dunlap @ 2011-05-30 20:30 ` Arnaud Lacombe 2011-05-30 21:04 ` Arnd Bergmann 2011-05-30 21:16 ` Randy Dunlap 1 sibling, 2 replies; 89+ messages in thread From: Arnaud Lacombe @ 2011-05-30 20:30 UTC (permalink / raw) To: Arnd Bergmann Cc: Randy Dunlap, David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel Hi, On Mon, May 30, 2011 at 2:40 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 30 May 2011 19:27:31 Randy Dunlap wrote: >> On Mon, 30 May 2011 13:05:58 +0200 Arnd Bergmann wrote: >> >> Ingo recently wrote: >> | When it wont boot straight away (often it does) i use a >> | Kconfig-needed set of minimal set of configs that enables the minimal >> | hardware environment. >> >> which I believe is the same method that is documented in >> Documentation/kbuild/kconfig.txt, subject "KCONFIG_ALLCONFIG": (partial text) >> >> This enables you to create "miniature" config (miniconfig) or custom >> config files containing just the config symbols that you are interested >> in. Then the kernel config system generates the full .config file, >> including symbols of your miniconfig file. >> >> This 'KCONFIG_ALLCONFIG' file is a config file which contains >> (usually a subset of all) preset config symbols. These variable >> settings are still subject to normal dependency checks. >> > > Very nice, I didn't know about it. Unfortunately, this seems to > suffer from the same problem as the generic "randconfig" -- it > ignores all "choice" statements and just uses the default: > > Try for instance > > KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make \ > O=obj-allmod/ allnoconfig ARCH=arm > > This is supposed to set CONFIG_ARCH_OMAP, but it instead chooses > CONFIG_ARCH_VERSATILE, which means it's still useless for me. > hum... % git describe v2.6.39 % KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make ARCH=arm allnoconfig scripts/kconfig/conf --allnoconfig Kconfig arch/arm/configs/omap2plus_defconfig:92:warning: symbol value 'm' invalid for BT_L2CAP arch/arm/configs/omap2plus_defconfig:93:warning: symbol value 'm' invalid for BT_SCO warning: (ARCH_STMP3XXX && ARCH_OMAP3 && ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) warning: (ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet direct dependencies (CACHE_L2X0) warning: (ARCH_OMAP4) selects PL310_ERRATA_727915 which has unmet direct dependencies (CACHE_L2X0) # # configuration written to .config # % grep CONFIG_ARCH_OMAP .config CONFIG_ARCH_OMAP=y # CONFIG_ARCH_OMAP1 is not set CONFIG_ARCH_OMAP2PLUS=y # CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set CONFIG_ARCH_OMAP2=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP4=y did I missed something ? - Arnaud ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 20:30 ` Arnaud Lacombe @ 2011-05-30 21:04 ` Arnd Bergmann 2011-05-30 21:16 ` Randy Dunlap 1 sibling, 0 replies; 89+ messages in thread From: Arnd Bergmann @ 2011-05-30 21:04 UTC (permalink / raw) To: Arnaud Lacombe Cc: Randy Dunlap, David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel On Monday 30 May 2011 22:30:14 Arnaud Lacombe wrote: > % KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make ARCH=arm > allnoconfig > scripts/kconfig/conf --allnoconfig Kconfig > arch/arm/configs/omap2plus_defconfig:92:warning: symbol value 'm' > invalid for BT_L2CAP > arch/arm/configs/omap2plus_defconfig:93:warning: symbol value 'm' > invalid for BT_SCO > warning: (ARCH_STMP3XXX && ARCH_OMAP3 && ARCH_OMAP4) selects > USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) > warning: (ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet > direct dependencies (CACHE_L2X0) > warning: (ARCH_OMAP4) selects PL310_ERRATA_727915 which has unmet > direct dependencies (CACHE_L2X0) > # > # configuration written to .config > # > > % grep CONFIG_ARCH_OMAP .config > CONFIG_ARCH_OMAP=y > # CONFIG_ARCH_OMAP1 is not set > CONFIG_ARCH_OMAP2PLUS=y > # CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set > CONFIG_ARCH_OMAP2=y > CONFIG_ARCH_OMAP3=y > CONFIG_ARCH_OMAP4=y > > did I missed something ? I figured it out now. I was using a separate object directory, which caused the relative file name arch/arm/configs/omap2plus_defconfig not to be found and the KCONFIG_ALLCONFIG option to be silently dropped. I misinterpreted the resulting .config file as one that only got the choice statements wrong, when in fact it had not taken any default values that I passed. In short, everything's fine except for a missing warning message when the allconfig snippet is not found, and me making a fool of myself. It did solve one of my problems in the end, so I'm happy. Arnd ^ permalink raw reply [flat|nested] 89+ messages in thread
* Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' 2011-05-30 20:30 ` Arnaud Lacombe 2011-05-30 21:04 ` Arnd Bergmann @ 2011-05-30 21:16 ` Randy Dunlap 1 sibling, 0 replies; 89+ messages in thread From: Randy Dunlap @ 2011-05-30 21:16 UTC (permalink / raw) To: Arnaud Lacombe Cc: Arnd Bergmann, David Woodhouse, John Stultz, Ingo Molnar, x86, linux-kernel On Mon, 30 May 2011 16:30:14 -0400 Arnaud Lacombe wrote: > Hi, > > On Mon, May 30, 2011 at 2:40 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Monday 30 May 2011 19:27:31 Randy Dunlap wrote: > >> On Mon, 30 May 2011 13:05:58 +0200 Arnd Bergmann wrote: > >> > >> Ingo recently wrote: > >> | When it wont boot straight away (often it does) i use a > >> | Kconfig-needed set of minimal set of configs that enables the minimal > >> | hardware environment. > >> > >> which I believe is the same method that is documented in > >> Documentation/kbuild/kconfig.txt, subject "KCONFIG_ALLCONFIG": (partial text) > >> > >> This enables you to create "miniature" config (miniconfig) or custom > >> config files containing just the config symbols that you are interested > >> in. Then the kernel config system generates the full .config file, > >> including symbols of your miniconfig file. > >> > >> This 'KCONFIG_ALLCONFIG' file is a config file which contains > >> (usually a subset of all) preset config symbols. These variable > >> settings are still subject to normal dependency checks. > >> > > > > Very nice, I didn't know about it. Unfortunately, this seems to > > suffer from the same problem as the generic "randconfig" -- it > > ignores all "choice" statements and just uses the default: > > > > Try for instance > > > > KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make \ > > O=obj-allmod/ allnoconfig ARCH=arm > > > > This is supposed to set CONFIG_ARCH_OMAP, but it instead chooses > > CONFIG_ARCH_VERSATILE, which means it's still useless for me. > > > hum... > > % git describe > v2.6.39 > > % KCONFIG_ALLCONFIG=arch/arm/configs/omap2plus_defconfig make ARCH=arm > allnoconfig > scripts/kconfig/conf --allnoconfig Kconfig > arch/arm/configs/omap2plus_defconfig:92:warning: symbol value 'm' > invalid for BT_L2CAP > arch/arm/configs/omap2plus_defconfig:93:warning: symbol value 'm' > invalid for BT_SCO > warning: (ARCH_STMP3XXX && ARCH_OMAP3 && ARCH_OMAP4) selects > USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) > warning: (ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet > direct dependencies (CACHE_L2X0) > warning: (ARCH_OMAP4) selects PL310_ERRATA_727915 which has unmet > direct dependencies (CACHE_L2X0) > # > # configuration written to .config > # > > % grep CONFIG_ARCH_OMAP .config > CONFIG_ARCH_OMAP=y > # CONFIG_ARCH_OMAP1 is not set > CONFIG_ARCH_OMAP2PLUS=y > # CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set > CONFIG_ARCH_OMAP2=y > CONFIG_ARCH_OMAP3=y > CONFIG_ARCH_OMAP4=y > > did I missed something ? > > - Arnaud Hey Arnaud, Thanks. I thought that I recalled some efforts being made in this area and I checked my email folder but not git logs... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 89+ messages in thread
end of thread, other threads:[~2011-07-31 21:51 UTC | newest] Thread overview: 89+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-29 22:14 [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' David Woodhouse 2011-05-30 7:23 ` Ingo Molnar 2011-05-30 8:57 ` David Woodhouse 2011-05-30 9:15 ` Ingo Molnar 2011-05-30 9:27 ` David Woodhouse 2011-05-30 9:53 ` Ingo Molnar 2011-05-30 10:06 ` David Woodhouse 2011-05-30 10:25 ` Ingo Molnar 2011-05-30 11:01 ` David Woodhouse 2011-05-30 11:04 ` Ingo Molnar 2011-05-30 11:12 ` David Woodhouse 2011-05-30 11:42 ` Ingo Molnar 2011-05-30 11:55 ` David Woodhouse 2011-05-30 12:11 ` Ingo Molnar 2011-05-31 8:53 ` Geert Uytterhoeven 2011-05-31 10:48 ` Ingo Molnar 2011-05-30 10:40 ` Alexey Dobriyan 2011-05-30 10:09 ` [PATCH v2] x86, kconfig: Pick up the .config arch version " David Woodhouse 2011-06-24 13:37 ` Michal Marek 2011-06-24 14:45 ` David Woodhouse 2011-05-30 10:42 ` [PATCH] Fix corruption of CONFIG_X86_32 " Ingo Molnar 2011-05-30 10:46 ` Ingo Molnar 2011-05-30 10:53 ` Theodore Tso 2011-05-30 10:58 ` Ingo Molnar 2011-05-30 11:04 ` Theodore Tso 2011-05-30 11:30 ` Ingo Molnar 2011-05-30 17:29 ` Randy Dunlap 2011-05-30 11:57 ` David Woodhouse 2011-05-30 12:14 ` Ingo Molnar 2011-05-30 19:03 ` David Woodhouse 2011-05-30 19:55 ` Ted Ts'o 2011-05-30 20:12 ` David Woodhouse 2011-05-30 22:39 ` [PATCH] Enable 'make CONFIG_FOO=y oldconfig' David Woodhouse 2011-05-31 0:24 ` Arnaud Lacombe 2011-05-31 15:48 ` David Woodhouse 2011-05-31 16:12 ` Arnaud Lacombe 2011-06-24 13:49 ` Michal Marek 2011-07-29 23:32 ` [PATCH v2] " David Woodhouse 2011-07-30 1:15 ` Arnaud Lacombe 2011-07-30 9:04 ` David Woodhouse 2011-07-30 0:49 ` [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse 2011-07-30 1:26 ` Arnaud Lacombe 2011-07-30 1:26 ` Arnaud Lacombe 2011-07-30 8:37 ` David Woodhouse 2011-07-30 15:21 ` Arnaud Lacombe 2011-07-30 15:52 ` Arnaud Lacombe 2011-07-30 16:19 ` David Woodhouse 2011-07-30 16:33 ` Arnaud Lacombe 2011-07-30 18:59 ` H. Peter Anvin 2011-07-30 20:58 ` David Woodhouse 2011-07-30 22:03 ` H. Peter Anvin 2011-07-30 22:17 ` David Woodhouse 2011-07-30 22:21 ` H. Peter Anvin 2011-07-30 22:24 ` Arnaud Lacombe 2011-07-30 22:34 ` David Woodhouse 2011-07-30 22:39 ` H. Peter Anvin 2011-07-30 22:21 ` Arnaud Lacombe 2011-07-30 22:57 ` David Woodhouse 2011-07-31 19:40 ` Arnaud Lacombe 2011-07-31 20:00 ` David Woodhouse 2011-07-31 20:24 ` Arnaud Lacombe 2011-07-31 20:51 ` David Woodhouse 2011-07-31 5:18 ` Arnaud Lacombe 2011-07-31 8:13 ` David Woodhouse 2011-07-31 21:47 ` Arnaud Lacombe 2011-07-31 21:51 ` Arnaud Lacombe 2011-05-31 1:44 ` [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig' Ted Ts'o 2011-05-31 8:37 ` David Woodhouse 2011-05-31 7:53 ` Ingo Molnar 2011-05-31 8:55 ` David Woodhouse 2011-05-31 10:41 ` Ingo Molnar 2011-05-31 11:43 ` David Woodhouse 2011-05-31 12:45 ` Ingo Molnar 2011-05-31 13:44 ` David Woodhouse 2011-05-31 13:56 ` Ingo Molnar 2011-05-31 14:31 ` David Woodhouse 2011-05-31 14:14 ` Geert Uytterhoeven 2011-05-31 12:12 ` Ted Ts'o 2011-05-31 12:32 ` David Woodhouse 2011-05-31 12:50 ` Ingo Molnar 2011-05-30 11:06 ` David Woodhouse 2011-05-30 11:34 ` Ingo Molnar 2011-05-30 11:05 ` Arnd Bergmann 2011-05-30 17:27 ` Randy Dunlap 2011-05-30 18:40 ` Arnd Bergmann 2011-05-30 20:01 ` Randy Dunlap 2011-05-30 20:30 ` Arnaud Lacombe 2011-05-30 21:04 ` Arnd Bergmann 2011-05-30 21:16 ` Randy Dunlap
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.