- 04 11月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 16 10月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 12 10月, 2009 2 次提交
-
-
由 Linus Torvalds 提交于
-
由 Sam Ravnborg 提交于
Revert commit 57554334 It caused following issues: - On architectures where ARCH= setting is used to select between 32 and 64 bit this was no longer possible without "make mrproper" - If ARCH was changed then kbuild refused to run "make mrproper" because ARCH had changed - When CROSS_COMPILE was changed people were asked to run "make mrproper" but kbuild refused to run "make mrproper" because CROSS_COMPILE changed. - Spaces in CROSS_COMPILE was not 'supported' - If an non-existing ARCH= was used kbuild could get stuck Lessons learned: . Despite being simple and straghtforward people uses very different approaches when building the kernel. . CROSS_COMPILE is sometimes used for ccache despite cache being only a CC frontend so one would have expected CC to be used for this purpose. . And obviously this was not tested widely enough. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org>
-
- 05 10月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
I'm skipping -rc2 because the -rc1 Makefile mistakenly said -rc2, so in order to avoid confusion, I'm jumping from -rc1 to -rc3. That way, when 'uname' (or an oops report) says 2.6.32-rc2, there's no confusion about whether people perhaps meant -rc1 or -rc2.
-
- 28 9月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 20 9月, 2009 6 次提交
-
-
由 Sam Ravnborg 提交于
Albin Tonnerre <albin.tonnerre@free-electrons.com> reported: Bash 4 filters out variables which contain a dot in them. This happends to be the case of CPPFLAGS_vmlinux.lds. This is rather unfortunate, as it now causes build failures when using SHELL=/bin/bash to compile, or when bash happens to be used by make (eg when it's /bin/sh) Remove the common definition of CPPFLAGS_vmlinux.lds by pushing relevant stuff to either Makefile.build or the arch specific kernel/Makefile where we build the linker script. This is also nice cleanup as we move the information out where it is used. Notes for the different architectures touched: arm - we use an already exported symbol cris - we use a config symbol aleady available [Not build tested] mips - the jiffies complexity has moved to vmlinux.lds.S where we need it. Added a few variables to CPPFLAGS - they are only used by the linker script. [Not build tested] powerpc - removed assignment that is not needed [not build tested] sparc - simplified it using $(BITS) um - introduced a few new exported variables to deal with this xtensa - added options to CPP invocation [not build tested] Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Andi Kleen 提交于
The upcomming gcc 4.5 has a new -fconserve-stack option that tells the inliner to take stack frame size in account. Set it if the compiler supports it. Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Andi Kleen 提交于
The new alternative `gold' linker in recent binutils doesn't support the -X option. This breaks allyesconfig builds that have CONFIG_STRIP_ASM_SYMS enabled. Check if the linker really supports the option using ld-option. Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Sam Ravnborg 提交于
ld-option is misnamed as it test options to gcc, not to ld. Renamed it to reflect this. Cc: Andi Kleen <andi@firstfloor.org> Cc: Roland McGrath <roland@redhat.com> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Sam Ravnborg 提交于
When building a kernel for a different architecture kbuild requires the user always to specify ARCH and CROSS_COMPILE on the command-line. We use the asm symlink to detect if user forgets to specify the correct ARCH value - but that symlink is about to die. And we do now want to loose this check. This patch save the settings of ARCH and CROSS_COMPILE in two files named: include/generated/kernel.arch include/generated/kernel.cross The settings are saved during "make *config" time and always read. If user try to change the settings we error out. This works both for plain builds and for O=... builds. So now you can do: $ mkdir sparc64 $ make O=sparc64 ARCH=sparc64 CROSS_COMPILE=sparc64-linux- defconfig $ cd sparc64 $ make Notice that you no longer need to tell kbuild the settings of ARCH and CROSS_COMPILE when you type make in the output directory. Likewise for plain builds where you do not use O=... Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Roland McGrath <roland@redhat.com>
-
由 Sam Ravnborg 提交于
Replace the use of CROSS_COMPILE to select a customized installkernel script with the possibility to set INSTALLKERNEL to select a custom installkernel script when running make: make INSTALLKERNEL=arm-installkernel install With this patch we are now more consistent across different architectures - they did not all support use of CROSS_COMPILE. The use of CROSS_COMPILE was a hack as this really belongs to gcc/binutils and the installkernel script does not change just because we change toolchain. The use of CROSS_COMPILE caused troubles with an upcoming patch that saves CROSS_COMPILE when a kernel is built - it would no longer be installable. [Thanks to Peter Z. for this hint] This patch undos what Ian did in commit: 0f8e2d62 ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh") The patch has been lightly tested on x86 only - but all changes looks obvious. Acked-by: NPeter Zijlstra <peterz@infradead.org> Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin] Acked-by: Russell King <linux@arm.linux.org.uk> [arm] Acked-by: Paul Mundt <lethal@linux-sh.org> [sh] Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86] Cc: Ian Campbell <icampbell@arcom.com> Cc: Tony Luck <tony.luck@intel.com> [ia64] Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64] Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r] Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k] Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc] Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc] Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390] Cc: Thomas Gleixner <tglx@linutronix.de> [x86] Cc: Ingo Molnar <mingo@redhat.com> [x86] Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 10 9月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 06 9月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 28 8月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 8月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 14 8月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 8月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 23 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 17 7月, 2009 1 次提交
-
-
由 Eugene Teo 提交于
Turning on this flag could prevent the compiler from optimising away some "useless" checks for null pointers. Such bugs can sometimes become exploitable at compile time because of the -O2 optimisation. See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html An example that clearly shows this 'problem' is commit 6bf67672. static void __devexit agnx_pci_remove(struct pci_dev *pdev) { struct ieee80211_hw *dev = pci_get_drvdata(pdev); - struct agnx_priv *priv = dev->priv; + struct agnx_priv *priv; AGNX_TRACE; if (!dev) return; + priv = dev->priv; By reverting this patch, and compile it with and without -fno-delete-null-pointer-checks flag, we can see that the check for dev is compiled away. call printk # - testq %r12, %r12 # dev - je .L94 #, movq %r12, %rdi # dev, Clearly the 'fix' is to stop using dev before it is tested, but building with -fno-delete-null-pointer-checks flag at least makes it harder to abuse. Signed-off-by: NEugene Teo <eugeneteo@kernel.sg> Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NWang Cong <amwang@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 13 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
This causes kernel images that don't run init to completion with certain broken gcc versions. This fixes kernel bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=13012 I suspect the gcc problem is this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230 Fix the problem by using the -fno-strict-overflow flag instead, which not only does not exist in the known-to-be-broken versions of gcc (it was introduced later than fwrapv), but seems to be much less disturbing to gcc too: the difference in the generated code by -fno-strict-overflow are smaller (compared to using neither flag) than when using -fwrapv. Reported-by: NBarry K. Nathan <barryn@pobox.com> Pushed-by: NFrans Pop <elendil@planet.nl> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 05 7月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 27 6月, 2009 2 次提交
-
-
由 Amerigo Wang 提交于
TOPDIR is obsolete, it can be finally removed now. Signed-off-by: NWANG Cong <amwang@redhat.com> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Floris Kraak 提交于
Some distributions have enabled the gcc flag -Wformat-security by default. This results in a number of warnings about format arguments to functions, sometimes in cases where fixing the warning is not likely to actually fix a bug. Instead of hand patching a dozens of places (possibly more) that produce warnings that get ignored anyway we just turn off the flag in the Makefile. Signed-off-by: NFloris Kraak <randakar@gmail.com> Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 25 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 24 6月, 2009 1 次提交
-
-
由 Tejun Heo 提交于
x86 throws away .discard section but no other archs do. Also, .discard is not thrown away while linking modules. Make every arch and module linking throw it away. This will be used to define dummy variables for percpu declarations and definitions. This patch is based on Ivan Kokshaysky's alpha percpu patch. [ Impact: always throw away everything in .discard ] Signed-off-by: NTejun Heo <tj@kernel.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Bryan Wu <cooloney@kernel.org> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: David Howells <dhowells@redhat.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Tony Luck <tony.luck@intel.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David S. Miller <davem@davemloft.net> Cc: Jeff Dike <jdike@addtoit.com> Cc: Chris Zankel <chris@zankel.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Ingo Molnar <mingo@elte.hu>
-
- 19 6月, 2009 1 次提交
-
-
由 Peter Oberparleiter 提交于
Enable the use of GCC's coverage testing tool gcov [1] with the Linux kernel. gcov may be useful for: * debugging (has this code been reached at all?) * test improvement (how do I change my test to cover these lines?) * minimizing kernel configurations (do I need this option if the associated code is never run?) The profiling patch incorporates the following changes: * change kbuild to include profiling flags * provide functions needed by profiling code * present profiling data as files in debugfs Note that on some architectures, enabling gcc's profiling option "-fprofile-arcs" for the entire kernel may trigger compile/link/ run-time problems, some of which are caused by toolchain bugs and others which require adjustment of architecture code. For this reason profiling the entire kernel is initially restricted to those architectures for which it is known to work without changes. This restriction can be lifted once an architecture has been tested and found compatible with gcc's profiling. Profiling of single files or directories is still available on all platforms (see config help text). [1] http://gcc.gnu.org/onlinedocs/gcc/Gcov.htmlSigned-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Huang Ying <ying.huang@intel.com> Cc: Li Wei <W.Li@Sun.COM> Cc: Michael Ellerman <michaele@au1.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Heiko Carstens <heicars2@linux.vnet.ibm.com> Cc: Martin Schwidefsky <mschwid2@linux.vnet.ibm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: WANG Cong <xiyou.wangcong@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jeff Dike <jdike@addtoit.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 10 6月, 2009 2 次提交
-
-
由 Linus Torvalds 提交于
-
由 Cheng Renquan 提交于
The GNU make's origin function know undefined variable well, so the outer ifdef/endif conditional checking is unneeded. From `info make` documentation, origin will return `undefined' if VARIABLE was never defined. `command line' if VARIABLE was defined on the command line. ... Therefore, $(origin V) will get a value anyway, killing ifdef/endif is viable and safe. Furthermore, I've checked the minimal requirements from Documentation/Changes is GNU make 3.79.1, and that version of GNU make has support of origin function well already, so now it's safe to kill the outer conditional checking, without upgrading the minimal requirements. Signed-off-by: NCheng Renquan <crq@kernel.org> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 05 6月, 2009 1 次提交
-
-
由 Mike Frysinger 提交于
The checking of CONFIG_FRAME_WARN in the top level Makefile forgot to actually derefence the variable thus leading to an always true check. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Cc: Andi Kleen <ak@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 24 5月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 16 5月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 09 5月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 5月, 2009 2 次提交
-
-
由 Robert P. J. Day 提交于
Correct the Makefile help text to read "make modules_prepare". Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
由 Frédéric Brière 提交于
Signed-off-by: NFrédéric Brière <fbriere@fbriere.net> Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 30 4月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 4月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 19 4月, 2009 1 次提交
-
-
由 Sam Ravnborg 提交于
We need a location for generated files. Today they are spread over several places and bringing them together to a common place makes it obvious hat is generated and what isreal files. Al Viro originally suggested: include/gen Linus suggested to spell it out. This patch implement support for include/generated All files in include/generated are ignored by git. include/generated is removed during "make mrproper". With this we are ready to implement support for include/generated in the various architctures and in the base kernel. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org>
-