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 <[email protected]>
---
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
[email protected] Intel Corporation
* David Woodhouse <[email protected]> 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 <[email protected]>
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 <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
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
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
* David Woodhouse <[email protected]> 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
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
* David Woodhouse <[email protected]> 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
On Mon, 2011-05-30 at 11:53 +0200, Ingo Molnar wrote:
> * David Woodhouse <[email protected]> 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
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 <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
---
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
* David Woodhouse <[email protected]> wrote:
> On Mon, 2011-05-30 at 11:53 +0200, Ingo Molnar wrote:
> > * David Woodhouse <[email protected]> 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
On Mon, May 30, 2011 at 12:27 PM, David Woodhouse <[email protected]> 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.
* David Woodhouse <[email protected]> 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
* Ingo Molnar <[email protected]> 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
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
* Theodore Tso <[email protected]> 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
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
On May 30, 2011, at 6:58 AM, Ingo Molnar wrote:
>
> * Theodore Tso <[email protected]> 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
* David Woodhouse <[email protected]> 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
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
On Mon, 2011-05-30 at 12:58 +0200, Ingo Molnar wrote:
>
> * Theodore Tso <[email protected]> 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
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
* Theodore Tso <[email protected]> wrote:
>
> On May 30, 2011, at 6:58 AM, Ingo Molnar wrote:
>
> >
> > * Theodore Tso <[email protected]> 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
* David Woodhouse <[email protected]> wrote:
> On Mon, 2011-05-30 at 12:58 +0200, Ingo Molnar wrote:
> >
> > * Theodore Tso <[email protected]> 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
* David Woodhouse <[email protected]> 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
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
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
* David Woodhouse <[email protected]> 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
* David Woodhouse <[email protected]> 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
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 ***
On Mon, 30 May 2011 13:30:36 +0200 Ingo Molnar wrote:
>
> * Theodore Tso <[email protected]> wrote:
>
> >
> > On May 30, 2011, at 6:58 AM, Ingo Molnar wrote:
> >
> > >
> > > * Theodore Tso <[email protected]> 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 ***
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
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
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
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 ***
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
Hi,
On Mon, May 30, 2011 at 2:40 PM, Arnd Bergmann <[email protected]> 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
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
On Mon, 30 May 2011 16:30:14 -0400 Arnaud Lacombe wrote:
> Hi,
>
> On Mon, May 30, 2011 at 2:40 PM, Arnd Bergmann <[email protected]> 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 ***
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 <[email protected]>
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
Hi,
On Mon, May 30, 2011 at 6:39 PM, David Woodhouse <[email protected]> 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 <[email protected]>
>
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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
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
* David Woodhouse <[email protected]> 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
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
On Mon, May 30, 2011 at 12:25, Ingo Molnar <[email protected]> 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 -- [email protected]
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
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
* David Woodhouse <[email protected]> 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
* Geert Uytterhoeven <[email protected]> wrote:
> On Mon, May 30, 2011 at 12:25, Ingo Molnar <[email protected]> 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
On Tue, 2011-05-31 at 12:41 +0200, Ingo Molnar wrote:
> * David Woodhouse <[email protected]> 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
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
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
* David Woodhouse <[email protected]> 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: <[email protected]>
"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: <[email protected]>
"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: <[email protected]>
" 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
* Ted Ts'o <[email protected]> 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
On Tue, 2011-05-31 at 14:45 +0200, Ingo Molnar wrote:
> * David Woodhouse <[email protected]> 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: <[email protected]>
>
> "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: <[email protected]>
>
> "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: <[email protected]>
>
> " 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
* David Woodhouse <[email protected]> wrote:
> On Tue, 2011-05-31 at 14:45 +0200, Ingo Molnar wrote:
> > * David Woodhouse <[email protected]> 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
On Tue, May 31, 2011 at 13:43, David Woodhouse <[email protected]> wrote:
> On Tue, 2011-05-31 at 12:41 +0200, Ingo Molnar wrote:
>> * David Woodhouse <[email protected]> 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 -- [email protected]
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
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
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
[email protected] Intel Corporation
Hi,
On Tue, May 31, 2011 at 11:48 AM, David Woodhouse <[email protected]> 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
> [email protected] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Intel Corporation
>
>
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<[email protected]>
> Link: http://lkml.kernel.org/r/[email protected]
>
> ---
> 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
On 31.5.2011 18:12, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, May 31, 2011 at 11:48 AM, David Woodhouse<[email protected]> 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
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