- 18 12月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 12 12月, 2009 12 次提交
-
-
由 Michal Marek 提交于
Fix typo / thinko in commit bc081dd6. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Michal Marek 提交于
To make it easier for module-init-tools and scripts like mkinitrd to distinguish builtin and missing modules, install a modules.builtin file listing all builtin modules. This is done by generating an additional config file (tristate.conf) with tristate options set to uppercase 'Y' or 'M'. If we source that config file, the builtin modules appear in obj-Y. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Michal Marek 提交于
The toplevel Makefile creates the directory if it runs silentoldconfig automatically, but if run manually, it fails: $ make mrproper $ make defconfig && make silentoldconfig *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # scripts/kconfig/conf -s arch/x86/Kconfig *** Error during update of the kernel configuration. ... Move the mkdir command to the silentoldconfig target to make it work. Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Wenji Huang 提交于
Drop Module.markers from cleaning list since marker is removed. Signed-off-by: NWenji Huang <wenji.huang@oracle.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
Fix up all users of utsrelease.h Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
We no longer use this directory for generated files and all architectures has moved their header files so no symlink tricks are needed either. Drop the symlink and drop the ARCH check. If we really need to check that the SRCARCH has not changed when we build a kernel we can add this check back - but then we will find a more convenient way to store the info. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
No architectures uses include/asm-$ARCH now. So drop check for location of include files Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
There is no longer any use of the include2/ directory. The generated files has moved to include/generated. Drop all references to said directory. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
The simplest method was to add an extra asm-offsets.h file in arch/$ARCH/include/asm that references the generated file. We can now migrate the architectures one-by-one to reference the generated file direct - and when done we can delete the temporary arch/$ARCH/include/asm/asm-offsets.h file. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
由 Sam Ravnborg 提交于
The namespace used in arch/$ARCH/include is different from what is used in include/ except for the include/asm directory. This patch gives the arch/$ARCH/include/asm directory priority over include/asm. When we add asm-offsets.h to arch/$ARCH/include/asm/ this patch makes sure we pick up the arch specific version and not the one we have in include/asm. The situation with an asm-offsets.h file located in both include/asm _and_ arch/$ARCH/include/asm will happen when we move more files over to include/generated. This happens because in some cases it is not practical to rename all users so we simply add a file in arch/$ARCH/include/asm that includes the generated version. This is the solution we use for asm-offsets.h as an example. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 03 12月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 20 11月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 18 11月, 2009 1 次提交
-
-
由 Steven Rostedt 提交于
If the user has an older version of objcopy, that can not handle converting local symbols to global and vice versa, then some functions will not be part of the dynamic function tracer. The current code in recordmcount.pl will print a warning in this case. Unfortunately, there exists lots of files that may have this issue with older objcopys and this will cause a warning for every file compiled with this issue. This patch solves this overwhelming output by creating a .tmp_quiet_recordmcount file on the first instance the warning is encountered. The warning will not print if this file exists. The temp file is deleted at the beginning of the compile to ensure that the warning will happen once again on new compiles (because the issue is still present). Reported-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
-
- 16 11月, 2009 1 次提交
-
-
由 Josh Triplett 提交于
Now that all host programs use static for all private functions and forward prototypes for all extern functions, add -Wmissing-prototypes to HOSTCFLAGS in the hopes of keeping it that way. All versions of GCC supported by the kernel handle -Wmissing-prototypes. Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
-
- 13 11月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 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>
-