Kbuild is supposed to support mixed targets. (%config and build targets)

But "make all" did nothing if it was run with configuration targets.
For example,

  $ LANG=C make defconfig all
    HOSTCC  scripts/basic/fixdep
    HOSTCC  scripts/kconfig/conf.o
    SHIPPED scripts/kconfig/zconf.tab.c
    SHIPPED scripts/kconfig/zconf.lex.c
    SHIPPED scripts/kconfig/zconf.hash.c
    HOSTCC  scripts/kconfig/zconf.tab.o
    HOSTLD  scripts/kconfig/conf
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #
  make: Nothing to be done for `all'.

This commits allows "make %config all" and makes sure
mixed targets are built one by one in the given order.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Michal Marek <mmarek@suse.cz>
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

W=... provides extra gcc checks.

Having such code in scripts/Makefile.build results in the same flags
being added to KBUILD_CFLAGS multiple times becuase
scripts/Makefile.build is invoked every time Kbuild descends into
the subdirectories.

Since the top Makefile is already too cluttered, this commit moves
all of extra gcc check stuff to a new file scripts/Makefile.extrawarn,
which is included from the top Makefile.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Add support to toplevel Makefile for compiling with clang, both for
HOSTCC and CC. Use cc-option to prevent gcc option from breaking clang, and
from clang options from breaking gcc.

Clang 3.4 semantics are the same as gcc semantics for unsupported flags. For
unsupported warnings clang 3.4 returns true but shows a warning and gcc shows
a warning and returns false.
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Signed-off-by: NJan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: NMark Charlebois <charlebm@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>

objdiff is useful when doing large code cleanups.  For example, when
removing checkpatch warnings and errors from new drivers in the staging
tree.

objdiff can be used in conjunction with a git rebase to confirm that
each commit made no changes to the resulting object code.  It has the
same return values as diff(1).

This was written specifically to support adding the skein and threefish
cryto drivers to the staging tree.  I needed a programmatic way to
confirm that commits changing >90% of the lines didn't inadvertently
change the code.

Temporary files (objdump output) are stored in

  /path/to/linux/.tmp_objdiff

'make mrproper' will remove this directory.
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Kbuild supports saving output files in a separate directory.
But the build directory must be created beforehand. For example,

  $ mkdir -p dir/to/store/output/files
  $ make O=dir/to/store/output/files defconfig

Creating a build directory automatically would be useful.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

'.*.cmd' files are cleaned-up by "make clean".
The same pattern in "make distclean" is unnecessary.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

As of v3.7, the UAPI changes relocated headers around such that the
kernel version header lived in a new place.

If a person is bisecting and if you go back to pre-UAPI days,
you will create an include/linux/version.h  -- then if you checkout a
post-UAPI kernel, and even run "make distclean" it still won't delete
that old version file.  So you get a situation like this:

$ grep -R LINUX_VERSION_CODE include/
include/generated/uapi/linux/version.h:#define LINUX_VERSION_CODE 200192
include/linux/version.h:#define LINUX_VERSION_CODE 132646

The value in that second line is representative of a v2.6.38 version.
And it will be sourced/used, hence leading to strange behaviours, such
as drivers/staging content (which typically hasn't been purged of version
ifdefs) failing to build.

Since it is a subtle mode of failure, lets always clobber the old
file when doing a distclean.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions.  Commit 8779657d
("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however
introduced an "else ifdef" construct which make 3.80 doesn't understand.

Also correct a warning message still referencing the old config option
name.

Apart from that I question the use of "ifdef" here (but it was used that
way already prior to said commit): ifeq (,y) would seem more to the
point.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NKees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

An extra parenthesis typo introduced in 19952a92 ("stackprotector:
Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is
causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is
enabled:

  Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler
  Makefile:608: *** missing separator.  Stop.
Signed-off-by: NFathi Boudra <fathi.boudra@linaro.org>
Acked-by: NKees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.

This commit adds a new 'dtbs_install' make target which copies all of
the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
set before calling make to change the default install directory. If not
set then it defaults to:

	$INSTALL_PATH/dtbs/$KERNELRELEASE.

This is done to keep dtbs from different kernel versions separate until
things have settled down.  Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo.  Users will need to upgrade install scripts at that
time.

v7: (reworked by Grant Likely)
- Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
  that each dtb install could have a separate target and be reported as
  part of the make output.
- Fixed dependency problem to ensure $KERNELRELEASE is calculated before
  attempting to install
- Removed option to call external script. Copying the files should be
  sufficient and a build system can post-process the install directory.
  Despite the fact an external script is used for installing the kernel,
  I don't think that is a pattern that should be encouraged. I would
  rather see buildroot type tools post process the install directory to
  rename or move dtb files after installing to a staging directory.
  - Plus it is easy to add a hook after the fact without blocking the
    rest of this feature.
- Move the helper targets into scripts/Makefile.lib with the rest of the
  common dtb rules
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>

CONFIG_MODVERSIONS=y results in a .mod.c for every compiled file in the
kernel. Issuing a 'make cscope' on a compiled kernel tree results in
the cscope files containing *.mod.c files.

[prarit@prarit linux]# make cscope
[prarit@prarit linux]# cat cscope.files | grep mod.c | wc -l
4807

These files are not useful for cscope and should be ignored. For example,

   #   line  filename / context / line
   1    105  arch/x86/kvm/kvm-intel.mod.c <<GLOBAL>>
             { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
   2    508  drivers/block/mtip32xx/mtip32xx.h <<GLOBAL>>
             int numa_node;
   3     55  drivers/block/mtip32xx/mtip32xx.mod.c <<GLOBAL>>
             { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
   4     37  drivers/cpufreq/acpi-cpufreq.mod.c <<GLOBAL>>
             { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
   <snip>

Add an export to RCS_FIND_IGNORE so it can be used in scripts/tags.sh
and add explicitly ignore *.mod.c files.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill Tkhai <tkhai@yandex.ru>
Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use
of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build
non-deterministic.  Now that the kernel does not use any of those
macros, turn on -Werror=date-time if available, to keep it that way.

The kernel already (optionally) records this information at build time
in a single place; other kernel code should not duplicate that.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Change the debuging info generation flag in KBUILD_AFLAGS from '-gdwarf-2' to
'-Wa,--gdwarf-2'.  This will properly generate the debugging info for .S files
when CONFIG_DEBUG_INFO=y.

It seems current gcc does not pass a '--gdwarf-2' option on to the assembler
when '-gdwarf-2' is on its command line (note the differece in the gcc and as
flags).  This change provides the correct assembler flag to gcc, and so does
not rely on gcc to emit a flag for the assembler.

Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: NMichal Marek <mmarek@suse.cz>

make-4 changed the way/order it presents the command line options
into MAKEFLAGS

In make-3.8x, '-s' would always be first into a group of options
with the '-'/hyphen removed

$ make -p -s 2>/dev/null | grep ^MAKEFLAGS
MAKEFLAGS = sp

In make-4, '-s' seems to always be last into a group of options
with the '-'/hyphen removed

$ make -s -p 2>/dev/null | grep ^MAKEFLAGS
MAKEFLAGS = ps
Signed-off-by: NEmil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Commit 1bf49dd4 ("./Makefile: export initial ramdisk compression
config option") started setting the INITRD_COMPRESS environment variable
depending on which decompression models the kernel had available.

That is completely broken.

For example, we by default have CONFIG_RD_LZ4 enabled, and are able to
decompress such an initrd, but the user tools to *create* such an initrd
may not be availble.  So trying to tell dracut to generate an
lz4-compressed image just because we can decode such an image is
completely inappropriate.

Cc: J P <ppandit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This changes the stack protector config option into a choice of
"None", "Regular", and "Strong":

   CONFIG_CC_STACKPROTECTOR_NONE
   CONFIG_CC_STACKPROTECTOR_REGULAR
   CONFIG_CC_STACKPROTECTOR_STRONG

"Regular" means the old CONFIG_CC_STACKPROTECTOR=y option.

"Strong" is a new mode introduced by this patch. With "Strong" the
kernel is built with -fstack-protector-strong (available in
gcc 4.9 and later). This option increases the coverage of the stack
protector without the heavy performance hit of -fstack-protector-all.

For reference, the stack protector options available in gcc are:

-fstack-protector-all:
  Adds the stack-canary saving prefix and stack-canary checking
  suffix to _all_ function entry and exit. Results in substantial
  use of stack space for saving the canary for deep stack users
  (e.g. historically xfs), and measurable (though shockingly still
  low) performance hit due to all the saving/checking. Really not
  suitable for sane systems, and was entirely removed as an option
  from the kernel many years ago.

-fstack-protector:
  Adds the canary save/check to functions that define an 8
  (--param=ssp-buffer-size=N, N=8 by default) or more byte local
  char array. Traditionally, stack overflows happened with
  string-based manipulations, so this was a way to find those
  functions. Very few total functions actually get the canary; no
  measurable performance or size overhead.

-fstack-protector-strong
  Adds the canary for a wider set of functions, since it's not
  just those with strings that have ultimately been vulnerable to
  stack-busting. With this superset, more functions end up with a
  canary, but it still remains small compared to all functions
  with only a small change in performance. Based on the original
  design document, a function gets the canary when it contains any
  of:

    - local variable's address used as part of the right hand side
      of an assignment or function argument
    - local variable is an array (or union containing an array),
      regardless of array type or length
    - uses register local variables

  https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU

Find below a comparison of "size" and "objdump" output when built with
gcc-4.9 in three configurations:

  - defconfig
	11430641 kernel text size
	36110 function bodies

  - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
	11468490 kernel text size (+0.33%)
	1015 of 36110 functions are stack-protected (2.81%)

  - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
	11692790 kernel text size (+2.24%)
	7401 of 36110 functions are stack-protected (20.5%)

With -strong, ARM's compressed boot code now triggers stack
protection, so a static guard was added. Since this is only used
during decompression and was never used before, the exposure
here is very small. Once it switches to the full kernel, the
stack guard is back to normal.

Chrome OS has been using -fstack-protector-strong for its kernel
builds for the last 8 months with no problems.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org
[ Improved the changelog and descriptions some more. ]
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Instead of duplicating the CC_STACKPROTECTOR Kconfig and
Makefile logic in each architecture, switch to using
HAVE_CC_STACKPROTECTOR and keep everything in one place. This
retains the x86-specific bug verification scripts.
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1387481759-14535-2-git-send-email-keescook@chromium.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions.

Commit 1bf49dd4 ("./Makefile: export initial ramdisk compression
config option") however introduced "else ifeq" constructs which make
3.80 doesn't understand.  Replace the logic there with more conventional
(in the kernel build infrastructure) list constructs (except that the
list here is intentionally limited to exactly one element).
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: P J P <ppandit@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make menuconfig allows one to choose compression format of an initial
ramdisk image.  But this choice does not result in duly compressed ramdisk
image.  Because - $ make install - does not pass on the selected
compression choice to the dracut(8) tool, which creates the initramfs
file.  dracut(8) generates the image with the default compression, ie.
gzip(1).

This patch exports the selected compression option to a sub-shell
environment, so that it could be used by dracut(8) tool to generate
appropriately compressed initramfs images.

There isn't a straightforward way to pass on options to dracut(8) via
positional parameters.  Because it is indirectly invoked at the end of a $
make install sequence.

 # make install
   -> arch/$arch/boot/Makefile
    -> arch/$arch/boot/install.sh
     -> /sbing/installkernel ...
      -> /sbin/new-kernel-pkg ...
       -> /sbin/dracut ...
Signed-off-by: NP J P <ppandit@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When building the kernel in a shell which defines GREP_OPTIONS so that
grep behavior is modified, we can break the generation of the syscalls
table like so:

__SYSCALL_COMMON(^[[01;31m^[[K0^[[m^[[K, sys_read, sys_read)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K, sys_write, sys_write)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K0, sys_mprotect, sys_mprotect) ...

This is just the initial breakage, later we barf when generating
modules.

In this case, GREP_OPTIONS contains "--color=always" which adds the shell
colors markup and completely fudges the headers under ...generated/asm/.

Fix that by unexporting the GREP_OPTIONS variable for the whole kernel
build as we tend to use grep at a bunch of places.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NMichal Marek <mmarek@suse.cz>