.. except there are various scripts that really know that there are
three numbers, so it calls itself "3.0.0-rc1".
Hopefully by the time the final 3.0 is out, we'll have that extra zero
all figured out.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With this change, you can (and should) build with ARCH=tilepro for the
current 32-bit chips. Building with ARCH=tile continues to work, but
we've renamed the defconfig file to tilepro_defconfig for consistency.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
When mcount is called in a section that ftrace will not modify it into
a nop, we want to warn about this. But not warn about this always. Now
if the user builds the kernel with the option RECORDMCOUNT_WARN=1 then
the build will warn about mcount callers that are ignored and will just
waste execution time.
Acked-by: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Link: http://lkml.kernel.org/r/20110421023738.714956282@goodmis.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
This support was partially present in the existing code (look for
"__tilegx__" ifdefs) but with this change you can build a working
kernel using the TILE-Gx toolchain and ARCH=tilegx.
Most of these files are new, generally adding a foo_64.c file
where previously there was just a foo_32.c file.
The ARCH=tilegx directive redirects to arch/tile, not arch/tilegx,
using the existing SRCARCH mechanism in the top-level Makefile.
Changes to existing files:
- <asm/bitops.h> and <asm/bitops_32.h> changed to factor the
include of <asm-generic/bitops/non-atomic.h> in the common header.
- <asm/compat.h> and arch/tile/kernel/compat.c changed to remove
the "const" markers I had put on compat_sys_execve() when trying
to match some recent similar changes to the non-compat execve.
It turns out the compat version wasn't "upgraded" to use const.
- <asm/opcode-tile_64.h> and <asm/opcode_constants_64.h> were
previously included accidentally, with the 32-bit contents. Now
they have the proper 64-bit contents.
Finally, I had to hack the existing hacky drivers/input/input-compat.h
to add yet another "#ifdef" for INPUT_COMPAT_TEST (same as x86_64).
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [drivers/input]
This patch fixes the versioncheck target so it works when make is
invoked in KBUILD_OUTDIR.
Signed-off-by: Peter Foley <pefoley2@verizon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This patch fixes the includecheck target so it works when make is
invoked in KBUILD_OUTDIR.
Signed-off-by: Peter Foley <pefoley2@verizon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This patch fixes the headerdep target so it works when make is invoked
in KBUILD_OUTDIR.
Signed-off-by: Peter Foley <pefoley2@verizon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This patch adds some targets to PHONY so they are built even if a file
with the same name exists.
Signed-off-by: Peter Foley <pefoley2@verizon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
According to Documentation/Changes, the kernel should be buildable with
GNU make 3.80+. Commit 88d7be031f (kbuild:
Use a single clean rule for kernel and external modules) introduced the
"$(or" construct, which requires make 3.81. This causes "make clean" to
malfunction when it is used with external modules.
Replace "$(or" with an equivalent "$(if" expression, to restore backward
compatibility.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
Starting with 4.4, gcc will happily accept -Wno-<anything> in the
cc-option test and complain later when compiling a file that has some
other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of
the opposite option (without the no-). Introduce a new Makefile function
cc-disable-warning that does this and update two uses of cc-option in
the toplevel Makefile.
Reported-and-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Add support for make W=12, make W=123 and so on, to enable warnings from
multiple W= levels. Normally, make W=<level> does not include warnings
from the previous level.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-By: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0
It produces more false positives than useful warnings.
This can still be enabled using W=1
Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
There is an increasing amount of header files
shared between individual architectures in asm-generic.
To avoid a lot of dummy wrapper files that just
include the corresponding file in asm-generic provide
some basic support in kbuild for this.
With the following patch an architecture can maintain
a list of files in the file arch/$(ARCH)/include/asm/Kbuild
To use a generic file just add:
generic-y += <name-of-header-file.h>
For each file listed kbuild will generate the necessary
wrapper in arch/$(ARCH)/include/generated/asm.
When installing userspace headers a wrapper is likewise created.
The original inspiration for this came from the unicore32
patchset - although a different method is used.
The patch includes several improvements from Arnd Bergmann.
Michael Marek contributed Makefile.asm-generic.
Remis Baima did an intial implementation along to achive
the same - see https://patchwork.kernel.org/patch/13352/
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Guan Xuetao <guanxuetao@mprc.pku.edu.cn>
Tested-by: Guan Xuetao <guanxuetao@mprc.pku.edu.cn>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Remis Lima Baima <remis.developer@googlemail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Building a kernel with "make W=1" produces far too much noise to be
useful.
Divide the warning options in three groups:
W=1 - warnings that may be relevant and does not occur too often
W=2 - warnings that occur quite often but may still be relevant
W=3 - the more obscure warnings, can most likely be ignored
When building the whole kernel, those levels produce:
W=1 - 4859 warnings
W=2 - 1394 warnings
W=3 - 86666 warnings
respectively. Warnings have been counted with Geert's script at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/linux-log-summary.pl
Many warnings occur from .h files so fixing one file may have a nice
effect on the total number of warnings.
With these changes I am actually tempted to try W=1 now and then.
Previously there was just too much noise.
Borislav:
- make the W= levels exclusive
- move very noisy and making little sense for the kernel warnings to W=3
- drop -Woverlength-strings due to useless warning message
- copy explanatory text for the different warning levels to 'make help'
- recount warnings per level
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Borislav Petkov <bp@alien8.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
At the moment we have the CONFIG_KALLSYMS_EXTRA_PASS Kconfig switch,
which users can enable or disable while configuring the kernel. This
option is then used by 'make' to determine whether an extra kallsyms
pass is needed or not.
However, this approach is not nice and confusing, and this patch moves
CONFIG_KALLSYMS_EXTRA_PASS from Kconfig to Makefile instead. The
rationale is below.
1. CONFIG_KALLSYMS_EXTRA_PASS is really about the build time, not
run-time. There is no real need for it to be in Kconfig. It is
just an additional work-around which should be used only in rare
cases, when someone breaks kallsyms, so Kbuild/Makefile is much
better place for this option.
2. Grepping CONFIG_KALLSYMS_EXTRA_PASS shows that many defconfigs have
it enabled, probably not because they try to work-around a kallsyms
bug, but just because the Kconfig help text is confusing and does
not really make it clear that this option should not be used unless
except when kallsyms is broken.
3. And since many people have CONFIG_KALLSYMS_EXTRA_PASS enabled in
their Kconfig, we do might fail to notice kallsyms bugs in time. E.g.,
many testers use "make allyesconfig" to test builds, which will enable
CONFIG_KALLSYMS_EXTRA_PASS and kallsyms breakage will not be noticed.
To address that, this patch:
1. Kills CONFIG_KALLSYMS_EXTRA_PASS
2. Changes Makefile so that people can use "make KALLSYMS_EXTRA_PASS=1"
to enable the extra pass if needed. Additionally, they may define
KALLSYMS_EXTRA_PASS as an environment variable.
3. By default KALLSYMS_EXTRA_PASS is disabled and if kallsyms has issues,
"make" should print a warning and suggest using KALLSYMS_EXTRA_PASS
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
[mmarek: Removed make help text, is not necessary]
Signed-off-by: Michal Marek <mmarek@suse.cz>
While changing our build system over to use the headers_install target
as part of our klibc build, the following message started showing up in
our logs:
make[2]: `scripts/unifdef' is up to date.
It turns out that the build blindly invokes a recursive make on this
target, which causes make to emit this message when the target is
already up to date. This isn't seen for most targets as the rest of the
build relies primarily on the default target and on PHONY targets when
invoking make recursively.
Silence the above message when building unifdef as part of
headers_install by hiding it behind a new PHONY target called
"build_unifdef" that has an empty recipe.
Signed-off-by: Mike Waychison <mikew@google.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Add a 'W=1' Makefile switch which adds additional checking per build
object.
The idea behind this option is targeted at developers who, in the
process of writing their code, want to do the occasional
make W=1 [target.o]
and let gcc do more extensive code checking for them. Then, they
could eyeball the output for valid gcc warnings about various
bugs/discrepancies which are not reported during the normal build
process.
For more background information and a use case, read through this
thread: http://marc.info/?l=kernel-janitors&m=129802065918147&w=2
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Michal Marek <mmarek@suse.cz>
GNU GLOBAL (http://www.gnu.org/software/global/) is a source code tagging system
It is really cheap to support it in kbuild system.
Signed-off-by: Jianbin Kang <kjbmail@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
If you try to build a kernel with KCONFIG_CONFIG set (to a value
not equal to .config) and that config sets CONFIG_IKCONFIG then the
build will fail with:
make[1]: *** No rule to make target `.config', needed by \
`kernel/config_data.gz'. Stop.
because the kernel/Makefile contains a direct reference to .config.
This issue has been present since the introduction of KCONFIG_CONFIG
in 14cdd3c402.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Roman Zippel <zippel@linux-m68k.org>
CC: Michal Marek <mmarek@suse.cz>
Reviewed-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Add 'sparc32' ARCH target to test all{yes,mod}config for 32-bit build.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds