[PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Geert Uytterhoeven]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Alexey Dobriyan]

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.

[PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig'

[Michal Marek]

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

Re: [PATCH v2] x86, kconfig: Pick up the .config arch version in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Theodore Tso]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Theodore Tso]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Randy Dunlap]

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 ***

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ted Ts'o]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

[PATCH] Enable 'make CONFIG_FOO=y oldconfig'

[David Woodhouse]

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

Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig'

[Arnaud Lacombe]

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
>

Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig'

[David Woodhouse]

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

Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig'

[Arnaud Lacombe]

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
>
>

Re: [PATCH] Enable 'make CONFIG_FOO=y oldconfig'

[Michal Marek]

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

[PATCH v2] Enable 'make CONFIG_FOO=y oldconfig'

[David Woodhouse]

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

Re: [PATCH v2] Enable 'make CONFIG_FOO=y oldconfig'

[Arnaud Lacombe]

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
>
>

Re: [PATCH v2] Enable 'make CONFIG_FOO=y oldconfig'

[David Woodhouse]

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

[PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[H. Peter Anvin]

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.

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[H. Peter Anvin]

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.

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[H. Peter Anvin]

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.

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[H. Peter Anvin]

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.

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[David Woodhouse]

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

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>
>

Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

[Arnaud Lacombe]

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
>>
>>
>

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ted Ts'o]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Geert Uytterhoeven]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ted Ts'o]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[David Woodhouse]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Ingo Molnar]

* 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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Arnd Bergmann]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Randy Dunlap]

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 ***

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Arnd Bergmann]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Randy Dunlap]

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 ***

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Arnaud Lacombe]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Arnd Bergmann]

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

Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

[Randy Dunlap]

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 ***