This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git.
Pull mirroring updated .
- Aug 08, 2011
-
- Jul 29, 2011
-
-
Michal Marek authored
Replace the config_is_*() macros with a variant that allows for grepping for usage of CONFIG_* options in the code. Usage: if (IS_ENABLED(CONFIG_NUMA)) or #if IS_ENABLED(CONFIG_NUMA) The IS_ENABLED() macro evaluates to 1 if the argument is set (to either 'y' or 'm'), IS_BUILTIN() tests if the option is 'y' and IS_MODULE() test if the option is 'm'. Only boolean and tristate options are supported. Reviewed-by:
Arnaud Lacombe <lacombar@gmail.com> Acked-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
- Jul 22, 2011
-
- Jul 11, 2011
-
- Jul 04, 2011
-
- Jun 28, 2011
-
- Jun 21, 2011
-
- Jun 15, 2011
-
-
Michal Marek authored
The script has the executable bit in git, but plain old patch(1) can't create executable files. Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
- Jun 13, 2011
-
- Jun 09, 2011
-
-
Michal Marek authored
Do not bloat the Makefile with multiline shell statements. No user-visible change intended. Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
Michal Marek authored
expr treats all numbers as decimals, so prepending a zero is safe. Note that the KERNEL_VERSION() macro still takes three arguments, 3.0 has to be written as KERNEL_VERSION(3,0,0). Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
Michal Marek authored
Omit the second dot for releases without SUBLEVEL. If PATCHLEVEL is also empty, only display VERSION. Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
- Jun 06, 2011
-
- May 30, 2011
-
-
Linus Torvalds authored
.. 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>
-
- May 25, 2011
-
-
Chris Metcalf authored
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>
-
- May 19, 2011
-
- May 17, 2011
-
-
Steven Rostedt authored
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>
-
- May 16, 2011
-
-
Steven Rostedt authored
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>
-
- May 12, 2011
-
-
Chris Metcalf authored
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]
-
Peter Foley authored
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>
-
Peter Foley authored
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>
-
Peter Foley authored
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>
-
Peter Foley authored
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>
-
- May 11, 2011
-
-
Kevin Cernekee authored
According to Documentation/Changes, the kernel should be buildable with GNU make 3.80+. Commit 88d7be03 (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>
-
- May 10, 2011
-
- May 04, 2011
-
- May 03, 2011
-
-
Michal Marek authored
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>
-
- May 02, 2011
-
-
Peter Foley authored
Move docproc from scripts/basic to scripts so it is only built for *doc targets instead of every time the kernel is built.
-
Michal Marek authored
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>
-
- Apr 29, 2011
-
-
Dave Jones authored
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>
-
- Apr 28, 2011
-
-
Sam Ravnborg authored
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>
-
Sam Ravnborg authored
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>
-
- Apr 27, 2011
-
- Apr 20, 2011
-
-
Michal Marek authored
The D option of ar is only available in newer versions. Signed-off-by:
Michal Marek <mmarek@suse.cz>
-
- Apr 19, 2011
-
- Apr 15, 2011
-
-
Artem Bityutskiy authored
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>
-
- Apr 12, 2011
-
- Apr 06, 2011
-
- Mar 29, 2011
-
- Mar 17, 2011
-
-
Mike Waychison authored
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>
-