We need to hand down parallel build options like the internal make
--jobserver-fds one so that parallel builds can also happen when
building perf from the toplevel directory.

Make it so #1!
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1361374353-30385-3-git-send-email-bp@alien8.deSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

By popular demand, arch/aarch64 is now known as arch/arm64. However,
uname -m (and indeed the GNU triplet) still use aarch64 as the machine
string.

This patch fixes native builds of both the kernel and perf tools by
updating the relevant Makefiles to munge the output of uname -m and
set the ARCH variable appropriately.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

It is easy to waste a bunch of time when one takes a 32-bit .config
from a test machine and try to build it on a faster 64-bit system, and
its existing setting of CONFIG_64BIT=n gets *changed* to match the
build host.  Similarly, if one has an existing build tree it is easy
to trash an entire build tree that way.

This is because the default setting for $ARCH when discovered from
'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
which effectively force the setting of CONFIG_64BIT to match. We should
default to ARCH=x86 instead, finally completing the merge that we
started so long ago.

This patch preserves the behaviour of the legacy ARCH settings for commands
such as:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

... since making the value of CONFIG_64BIT actually random in that situation
is not desirable.

In time, perhaps we can retire this legacy use of the old ARCH= values.
We already have a way to override values for *any* config option, using
$KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
to keep ARCH={i386,x86_64} around as a special case just for overriding
CONFIG_64BIT.

We'd probably at least want to add a way to override config options from
the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
that though.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

If CONFIG_MODULE_SIG is set, and 'make modules_sign' is called then this
patch will cause the modules to get a signature appended.  The make target
is intended to be run after 'make modules_install', and will modify the
modules in-place in the installed location.  It can be used to produce
signed modules after they have been processed by distribution build
scripts.
Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor typo fix)

Since commit 1f2bfbd0 "kbuild:
link of vmlinux moved to a script" make clean with M=<dir>
argument (so cleaning external module) removes vmlinux,
System.map and couple of other files from the *main* kernel
build directory! This not what was happening before and almost
certainly not what one would expect.

This patch moves makes the clean target of the script called
only when !KBUILD_EXTMOD.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Cc: stable@vger.kernel.org [v3.5+]
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Verbose output variable is unnecessary because the command's echo is
already surpressed. Additionally because the block defines skip-makefile
the variable Q is not defined within the makefile, which can cause
problems if Q is defined in the users environment.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Honour the O= flag that was passed to a higher level Makefile and then passed
down as part of a tool build.

To make this work, the top-level Makefile passes the original O= flag and
subdir=tools to the tools/Makefile, and that in turn passes
subdir=$(O)/$(subdir)/foodir when building tool foo in directory
$(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
element is missing).

For example, take perf.  This is found in tools/perf/.  Assume we're building
into directory ~/zebra/, so we pass O=~/zebra to make.  Dependening on where
we run the build from, we see:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			~/zebra/tools/perf/
	linux/tools		~/zebra/perf/
	linux/tools/perf	~/zebra/

and if O= is not set, we get:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			linux/tools/perf/
	linux/tools		linux/tools/perf/
	linux/tools/perf	linux/tools/perf/

The output directories are created by the descend function if they don't
already exist.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.ukSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Honour the O= flag that was passed to a higher level Makefile and then passed
down as part of a tool build.

To make this work, the top-level Makefile passes the original O= flag and
subdir=tools to the tools/Makefile, and that in turn passes
subdir=$(O)/$(subdir)/foodir when building tool foo in directory
$(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
element is missing).

For example, take perf.  This is found in tools/perf/.  Assume we're building
into directory ~/zebra/, so we pass O=~/zebra to make.  Dependening on where
we run the build from, we see:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			~/zebra/tools/perf/
	linux/tools		~/zebra/perf/
	linux/tools/perf	~/zebra/

and if O= is not set, we get:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			linux/tools/perf/
	linux/tools		linux/tools/perf/
	linux/tools/perf	linux/tools/perf/

The output directories are created by the descend function if they don't
already exist.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.ukSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Turn sign-file into perl and merge in x509keyid.  The latter doesn't
need to be a separate script as it doesn't actually need to work out the
SHA1 sum of the X.509 certificate itself, since it can get that from the
X.509 certificate.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Linus deleted the old code and put signing on the install command,
I fixed it to extract the keyid and signer-name within sign-file
and cleaned up that script now it always signs in-place.

Some enthusiast should convert sign-key to perl and pull
x509keyid into it.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Several arch/*/include/uapi/asm/* header simply include the
corresponding <asm-generic/*> file. This patch allows such files to be
specified in uapi/asm/Kbuild via "generic-y += ..." to be automatically
generated (similar to asm/Kbuild).
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>

It doesn't, because the clean targets don't include kernel/Makefile, and
because two files were missing from the list.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Provide gitignore and make clean rules for extra files to hide and clean up the
extra files produced by module signing stuff once it is added.  Also add a
clean up rule for the module content extractor program used to extract the data
to be signed.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Plumb the UAPI Kbuilds into the user header installation and checking system.
As the headers are split the entries will be transferred across from the old
Kbuild files to the UAPI Kbuild files.

The changes made in this commit are:

 (1) Exported generated files (of which there are currently four) are moved to
     uapi/ directories under the appropriate generated/ directory, thus we
     get:

	include/generated/uapi/linux/version.h
	arch/x86/include/generated/uapi/asm/unistd_32.h
	arch/x86/include/generated/uapi/asm/unistd_64.h
	arch/x86/include/generated/uapi/asm/unistd_x32.h

     These paths were added to the build as -I flags in a previous patch.

 (2) scripts/Makefile.headersinst is now given the UAPI path to install from
     rather than the old path.

     It then determines the old path from that and includes that Kbuild also
     if it exists, thus permitting the headers to exist in either directory
     during the changeover.

     I also renamed the "install" variable to "installdir" as it refers to a
     directory not the install program.

 (3) scripts/headers_install.pl is altered to take a list of source file paths
     instead of just their names so that the makefile can tell it exactly
     where to find each file.

     For the moment, files can be obtained from one of four places for each
     output directory:

	.../include/uapi/foo/
	.../include/generated/uapi/foo/
	.../include/foo/
	.../include/generated/foo/

     The non-UAPI paths will be dropped later.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Move include/linux/version.h to the include/generated/ header directory.
A later patch will move it to include/uapi/generated/.

This allows us to get rid of the objhdr-y list.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Partition the header include path flags into two sets, one for kernelspace
builds and one for userspace builds.

Add the following directories to build after the ordinary include directories
so that #include will pick up the UAPI header directly if the kernel header
has been moved there.

The userspace set (represented by the USERINCLUDE make variable) contains:

	-I $(srctree)/arch/$(hdr-arch)/include/uapi
	-I arch/$(hdr-arch)/include/generated/uapi
	-I $(srctree)/include/uapi
	-I include/generated/uapi
	-include $(srctree)/include/linux/kconfig.h

and the kernelspace set (represented by the LINUXINCLUDE make variable)
contains:

	-I $(srctree)/arch/$(hdr-arch)/include
	-I arch/$(hdr-arch)/include/generated
	-I $(srctree)/include
	-I include		--- if not building in the source tree

plus everything in the USERINCLUDE set.

Then use USERINCLUDE in building the x86 boot code.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

This is a respin of an older patch sent by Sam Ravnborg:
  http://www.gossamer-threads.com/lists/linux/kernel/1530602

This patch removes the annoying warning:

Makefile:708: "WARNING: Appending $KCFLAGS (-Wno-sign-compare) from command
line to kernel $CFLAGS"

which is printed every time I use KCFLAFS. The commit which introduced the
warning:

69ee0b35 kbuild: do not pick up CFLAGS from the environment

tells about the problems when people have CFLAGS in their environment,
then switches to KCFLAFS which should be enough to solve the issue, but
it anyway introduces a warning. Drop this warning.
Signed-off-by: NOzan Çağlayan <ozancag@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Thanks to Andi Kleen, gcc 4.6.0 now supports -mfentry for x86
(and hopefully soon for other archs). What this does is to have
the function profiler start at the beginning of the function
instead of after the stack is set up. As plain -pg (mcount) is
called after the stack is set up, and in some cases can have issues
with the function graph tracer. It also requires frame pointers to
be enabled.

The -mfentry now calls __fentry__ at the beginning of the function.
This allows for compiling without frame pointers and even has the
ability to access parameters if needed.

If the architecture and the compiler both support -mfentry then
use that instead.

Link: http://lkml.kernel.org/r/20120807194059.392617243@goodmis.orgAcked-by: NH. Peter Anvin <hpa@linux.intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>