Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
all.config.

For a fix the diffstat is nice:
 6 files changed, 3 insertions(+), 36 deletions(-)

The patch reverts these commits:
 - 0f855aa6 ("kconfig: add helper to set
   config symbol from environment variable")
 - 2a113281 ("kconfig: use $K64BIT to
   set 64BIT with all*config targets")

Roman Zippel pointed out that kconfig supported string compares so
the additional complexity introduced by the above two patches were
not needed.

With this patch we have following behaviour:

  # make {allno,allyes,allmod,rand}config [ARCH=...]
  option \ host arch      | 32bit         | 64bit
  =====================================================
  ./.                     | 32bit         | 64bit
  ARCH=x86                | 32bit         | 32bit
  ARCH=i386               | 32bit         | 32bit
  ARCH=x86_64             | 64bit         | 64bit

The general rule are that ARCH= and native architecture takes
precedence over the configuration.

So make ARCH=i386 [whatever] will always build a 32-bit kernel
no matter what the configuration says.  The configuration will
be updated to 32-bit if it was configured to 64-bit and the
other way around.

This behaviour is consistent with previous behaviour so no
suprises here.

make ARCH=x86 will per default result in a 32-bit kernel but as
the only ARCH= value x86 allow the user to select between 32-bit
and 64-bit using menuconfig.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Herrmann <aherrman@arcor.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After unification of the Kconfig files and
introducing K64BIT support in kconfig
it required only trivial changes to enable
"make ARCH=x86".

With this patch you can build for x86_64 in several ways:
1) make ARCH=x86_64
2) make ARCH=x86 K64BIT=y
3) make ARCH=x86 menuconfig
   => select 64-bit

Likewise for i386 with the addition that
i386 is default is you say ARCH=x86.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>

For x86 ARCH may say i386 or x86_64 and soon x86.
Rely on CONFIG_X64_32 to select between 32/64 or just
hardcode the value as appropriate.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>

Too many people have CFLAGS set to support building userspace.
And now Kbuild picks up CFLAGS this caused troubles.

Although people should realise that setting CFLAGS has
a 'global' effect the impact on the kernel build is a suprise.
So change kbuild to pick up value from KCFLAGS that is
much less used.

When kbuild pick up a value it will warn like this:
Makefile:544: "WARNING: Appending $KCFLAGS (-O3) from environment to kernel $CFLAGS"
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Thomas Bächler <thomas@archlinux.org>
Cc: David Miller <davem@davemloft.net>
Cc: Ingo Molnar <mingo@redhat.com>

When configuring the kernel natively the uname matching is off,
so fix up the uname mangling to get the proper SUBARCH. Needs
an explicit range so that SH-5 doesn't break.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Moving the ARCH specific Makefiles for i386 and x86_64
required a litle bit tweaking in the top-lvel Makefile.

SRCARCH is now set in the top-level Makefile
because we need this info to include the correct
arch Makefile.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The patch is big.  Really big.  You just won't believe how vastly hugely
mindbogglingly big it is.  I mean you may think it's a long way down the
road to the chemist, but that's just peanuts to how big the patch from
2.6.23 is.

But it's all good.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

depmod from module-init-tools 3.3-pre2 are reported
to work fine in cross build.
depmod from module-init-tools 3.1-pre5 are known to SEGV

Do not workaround older module-init-tools bugs here.
The right fix is for users to upgrade module-init-tools.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>

make vmlinux would delete the content of $(MODVERDIR)
equals .tmp_versions. This caused a subsequent
make modules_install to fail.

Fix it so we clean the directory only for the
modules build - but we still unconditionally create it so
we can do:
make dir/file.ko
without a preceeding make modules.

Reported by David Miller <davem@davemloft.net>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: David Miller <davem@davemloft.net>

This removes a syntax error (seen building on Ubuntu Feisty).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

When building a specific module before doing a total kernel
build it failed because $(MORVERDIR) were missing.
Creating the MODVERDIR explicit (independent of KBUILD_MODULES)
fixed this. As a side-effect the MODVERDIR will be created
also for a non-module build - but no harm done by that.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Begin infrastructure for kernel code samples in the samples/ directory.
Add its Kconfig and Kbuild files.
Source its Kconfig file in all arch/ Kconfigs.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When building embedded systems in a cross-compile environment and
populating a target's file system image, we don't want to run the
depmod on the host as we may be building for a completely different
architecture. Since there's no such thing as a cross-depmod, we
just disable running depmod in the cross-compile case and we just
run depmod on the target at bootup.

Inspired by patches from Christian, Armin and Deepak.

This solves: http://bugzilla.kernel.org/show_bug.cgi?id=3881Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Christian Bjølevik <nafallo@magicalforest.se>
Cc: Deepak Saxena <dsaxena@mvista.com> and
Cc: Armin Kuster <akuster@mvista.com>,

remove .tmp_kallsyms*.S in cscope.files
Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

We often hit the situation where the asm symlink
in include/ points to the wrong architecture.
In 9 out of 10 cases thats because we forgot to set
ARCH but sometimes we just reused the same tree
for another ARCH. For the merged x86 tree we need
to create a new symlink but this is not obvious.
So with the following patch we check if the symlink
points to the correct architecture and error
out if this is not the case.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

otherwise get the two copy file list in SRCARCH

for cscope:
C symbol: start_kernel

  File           Function            Line
0 proto.h        <global>              11 extern void start_kernel(void );
1 start_kernel.h <global>              10 extern asmlinkage void __init start_kernel(void );
2 head32.c       i386_start_kernel     37 start_kernel();
3 head32.c       i386_start_kernel     37 start_kernel();
4 head64.c       x86_64_start_kernel   85 start_kernel();
5 head64.c       x86_64_start_kernel   85 start_kernel();
6 head_32.S      options              199 cmpb $0,%cl #the first CPU calls start_kernel
7 head_32.S      options              199 cmpb $0,%cl #the first CPU calls start_kernel
8 enlighten.c    xen_start_kernel    1145 start_kernel();
9 enlighten.c    xen_start_kernel    1145 start_kernel();
a lguest.c       lguest_init         1095 start_kernel();
b main.c         start_kernel         513 asmlinkage void __init start_kernel(void )

after the patch:
C symbol: start_kernel

  File           Function            Line
0 proto.h        <global>              11 extern void start_kernel(void );
1 start_kernel.h <global>              10 extern asmlinkage void __init start_kernel(void );
2 head32.c       i386_start_kernel     37 start_kernel();
3 head64.c       x86_64_start_kernel   85 start_kernel();
4 head_32.S      options              199 cmpb $0,%cl #the first CPU calls start_kernel
5 enlighten.c    xen_start_kernel    1145 start_kernel();
6 lguest.c       lguest_init         1095 start_kernel();
7 main.c         start_kernel         513 asmlinkage void __init start_kernel(void )
Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The variable CPPFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.

This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the
tree and enabling one to use:
make CPPFLAGS=...
to specify additional CPP commandline options.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The previous patches was preparation.
With this patch we can now say:
make CFLAGS=-Os vmlinux

And the option specified will be appended to the
options passed to gcc for C files.

For assembler use:
make AFLAGS=-foo vmlinux
for the same functionality.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of AFLAGS with KBUILD_AFLAGS all over
the tree.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.

One usecase is when trying to find gcc bugs but other
use cases has been requested too.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k

Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The main feature is that export_report now automatically works
for O= builds.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Change the invocations of make in the output directory Makefile and the
main Makefile for separate object trees to pass all goals to one $(MAKE)
via a new phony target "sub-make" and the existing target _all.

When compiling with separate object directories, a separate make is called
in the context of another directory (from the output directory the main
Makefile is called, the Makefile is then restarted with current directory
set to the object tree).  Before this patch, when multiple make command
goals are specified, each target results in a separate make invocation.
With make -j, these invocations may run in parallel, resulting in multiple
commands running in the same directory clobbering each others results.

I did not try to address make -j for mixed dot-config and no-dot-config
targets.  Because the order does matter, a solution was not obvious.
Perhaps a simple check for MAKEFLAGS having -j and refusing to run would
be appropriate.
Signed-off-by: NMilton Miller <miltonm@bga.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The assembler for a while now supports -gdwarf to generate source line info
just like the C compiler does.  Source-level assembly debugging sounds like an
oxymoron, but it is handy to be able to see the right source file and read its
comments rather than just the disassembly.  This patch enables -gdwarf for
assembly files when CONFIG_DEBUG_INFO=y and the assembler supports the option.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Jan Engelhardt <jengelh@computergmbh.de> reported:
You can cause a recursion in kbuild/make with the following:

make O=$PWD kernel/time.o
make mrproper

Of course no one would use O=$PWD (that's just the testcase),
but this happened too often:

/ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o
(Oops - should have been O=/ws/linux/obj-2.6.23!)

Fixed by an explicit test for this case - we error
out if output directory and source directory are the same.
Tested-by: NJan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

At the moment, running `make clean` in an external module directory does a
nice job of cleaning up with one exception: it leaves behind Modules.symvers.
Attached patch adds this file to the clean list for external modules.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Change the $(ARCH) dependency to $(SRCARCH) to honor the x86
namespace for i386 and x86_64.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Move the headers to include/asm-x86 and fixup the
header install make rules
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Preparatory patch for the source merge of arch/i386 and arch/x86_64
into arch/x86. Make scope and tags aware of SRCARCH
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Preparatory patch for the source merge of arch/i386 and arch/x86_64
into arch/x86. This allows to keep the original arch directories as
stubs for the main Makefiles, Kconfigs et. al during the transition
phase while having the code in the new arch/x86 directory.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

No, I didn't want to do this, but we had more stuff go in after -rc8
than we had in the previous -rc. Gaah.

Getting there...