[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091004191729.GA20203@merkur.ravnborg.org>
Date: Sun, 4 Oct 2009 21:17:29 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [regressions] Re: kbuild: save ARCH & CROSS_COMPILE when
building a kernel
On Sat, Oct 03, 2009 at 12:34:41PM +0200, Ingo Molnar wrote:
>
> Sam,
>
> that arch-cache thing introduced in:
>
> 5755433: kbuild: save ARCH & CROSS_COMPILE when building a kernel
>
> isnt working very well in my experience.
>
> 1) it's a nuisance in cross-builds (it broke several cross-build scripts
> of mine)
On the contrary it has helped me big time on my cross builds.
No need to script is all to remember to set the correct ARCH + CROSS_COMPILE
settings.
We should make the default case easy. And I consider the default case when
people fire up their shell and type:
make CROSS_COMPILE=arm-linux- ARCH=arm defconfig
When they hit something they fix it up and do a simple:
make
This is what this commit enables.
This commit is know to break scripts that expect that they can
seamlessly change CROSS_COMPILE or ARCH settings.
More on that below.
It is a nusiance that we have to instruct people to do a
make mrproper
But on the other hand what else can we do to make sure people base their
work on a clean tree when the change either ARCH or CROSS_COMPILE.
Albeit for the latter we could drop the check as kbuild would see the
change in the commandline anyway.
> 2) it makes it hard to switch from 32-bit x86 builds to 64-bit ones:
> previously i only needed 'make ARCH=i386 defconfig' and off we went -
> now i have to add a 'make mrproper' step.
x86 is a mess in respect to ARCH setting.
We have:
ARCH=i386 =>
- ARCH is set to i386
- 64BIT is forced to n
- defconfig is i386_defconfig
ARCH=x86 =>
- ARCH is set to x86
- 64BIT is configurable
- defconfig is set to x86_64_defconfig
ARCH=x86_64 =>
- ARCH is set to x86_64
- 64BIT is forced y
- defconfig is set to x86_64_defconfig
ARCH=""
- let `uname -m` determine ARCH setting and follow rules above
And now when um enters the scene everyone gets confused.
I think the correct way to fix this is to always set ARCH=x86 in the x86 case.
And i386/x86_64 is only a user-interface thing - not a valid ARCH setting.
Pushing this to sparc and sh would also simplify a few things.
We would loose one thing. The current ARCH setting is used to _remember_
how we were started out. So if you once used ARCH=i386 you will not
be allowed to change 64BIT to 'y'.
But using ARCH to remember this is ackward at best and I guess very few people
realise this.
I will try to take a look at this in the hope that the current 'um'
mess can be cleaned up as a side effect.
> 3) it can also get stuck:
>
> phoenix:~/linux/linux> make mrproper
> Makefile:571: /home/mingo/tip/arch/no/Makefile: No such file or directory
> make: *** No rule to make target `/home/mingo/tip/arch/no/Makefile'. Stop.
So you tried to configure a kernel with ARCH=no
The version I have now will ask you to do a:
make mrporper ARCH=no
But this is suboptimal.
> Dunno - why isnt the .config enough in terms of determining which
> architecture we are on? If we want more info we should put it into the
> .config - not some other hidden state. I do think a single file should
> carry all 'configuration state' - that makes it easier to reproduce
> things, etc. etc. Everything else is really just hindering us.
chicken and egg + a few other issues.
If I want to have ARCH moved to Kconfig then this better be a true option.
Which requires kconfig to read in Kconfig* for all architectures in one sweep.
There is so many corner cases around this that I gave up last time
I looked at it.
But maybe the correct solution would be to move CROSS_COMPILE to Kconfig space.
And only leave ARCH out...
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists