1. 08 8月, 2013 1 次提交
  2. 23 6月, 2013 1 次提交
  3. 28 5月, 2013 1 次提交
  4. 21 12月, 2012 1 次提交
    • D
      x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT · ffee0de4
      David Woodhouse 提交于
      It is easy to waste a bunch of time when one takes a 32-bit .config
      from a test machine and try to build it on a faster 64-bit system, and
      its existing setting of CONFIG_64BIT=n gets *changed* to match the
      build host.  Similarly, if one has an existing build tree it is easy
      to trash an entire build tree that way.
      
      This is because the default setting for $ARCH when discovered from
      'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
      which effectively force the setting of CONFIG_64BIT to match. We should
      default to ARCH=x86 instead, finally completing the merge that we
      started so long ago.
      
      This patch preserves the behaviour of the legacy ARCH settings for commands
      such as:
      
         make ARCH=x86_64 randconfig
         make ARCH=i386 randconfig
      
      ... since making the value of CONFIG_64BIT actually random in that situation
      is not desirable.
      
      In time, perhaps we can retire this legacy use of the old ARCH= values.
      We already have a way to override values for *any* config option, using
      $KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
      to keep ARCH={i386,x86_64} around as a special case just for overriding
      CONFIG_64BIT.
      
      We'd probably at least want to add a way to override config options from
      the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
      that though.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      ffee0de4
  5. 13 12月, 2012 1 次提交
  6. 16 10月, 2012 1 次提交
  7. 03 10月, 2012 1 次提交
    • J
      kbuild: Fix gcc -x syntax · b1e0d8b7
      Jean Delvare 提交于
      The correct syntax for gcc -x is "gcc -x assembler", not
      "gcc -xassembler". Even though the latter happens to work, the former
      is what is documented in the manual page and thus what gcc wrappers
      such as icecream do expect.
      
      This isn't a cosmetic change. The missing space prevents icecream from
      recognizing compilation tasks it can't handle, leading to silent kernel
      miscompilations.
      
      Besides me, credits go to Michael Matz and Dirk Mueller for
      investigating the miscompilation issue and tracking it down to this
      incorrect -x parameter syntax.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Bernhard Walle <bernhard@bwalle.de>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      b1e0d8b7
  8. 27 9月, 2012 1 次提交
  9. 21 9月, 2012 1 次提交
    • J
      x86/kbuild: archscripts depends on scripts_basic · 24cc7fb6
      Jeff Mahoney 提交于
      While building the SUSE kernel packages, which build the scripts,
      make clean, and then build everything, we have been running into spurious
      build failures. We tracked them down to a simple dependency issue:
      
      $ make mrproper
        CLEAN   arch/x86/tools
        CLEAN   scripts/basic
      $ cp patches/config/x86_64/desktop .config
      $ make archscripts
        HOSTCC  arch/x86/tools/relocs
      /bin/sh: scripts/basic/fixdep: No such file or directory
      make[3]: *** [arch/x86/tools/relocs] Error 1
      make[2]: *** [archscripts] Error 2
      make[1]: *** [sub-make] Error 2
      make: *** [all] Error 2
      
      This was introduced by commit
      6520fe55 (x86, realmode: 16-bit real-mode code support for relocs),
      which added the archscripts dependency to archprepare.
      
      This patch adds the scripts_basic dependency to the x86 archscripts.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      24cc7fb6
  10. 11 8月, 2012 1 次提交
  11. 24 6月, 2012 1 次提交
  12. 22 5月, 2012 2 次提交
  13. 19 5月, 2012 1 次提交
    • H
      x86, realmode: 16-bit real-mode code support for relocs tool · 6520fe55
      H. Peter Anvin 提交于
      A new option is added to the relocs tool called '--realmode'.
      This option causes the generation of 16-bit segment relocations
      and 32-bit linear relocations for the real-mode code. When
      the real-mode code is moved to the low-memory during kernel
      initialization, these relocation entries can be used to
      relocate the code properly.
      
      In the assembly code 16-bit segment relocations must be relative
      to the 'real_mode_seg' absolute symbol. Linear relocations must be
      relative to a symbol prefixed with 'pa_'.
      
      16-bit segment relocation is used to load cs:ip in 16-bit code.
      Linear relocations are used in the 32-bit code for relocatable
      data references. They are declared in the linker script of the
      real-mode code.
      
      The relocs tool is moved to arch/x86/tools/relocs.c, and added new
      target archscripts that can be used to build scripts needed building
      an architecture.  be compiled before building the arch/x86 tree.
      
      [ hpa: accelerating this because it detects invalid absolute
        relocations, a serious bug in binutils 2.22.52.0.x which currently
        produces bad kernels. ]
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.comSigned-off-by: NJarkko Sakkinen <jarkko.sakkinen@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      6520fe55
  14. 09 5月, 2012 1 次提交
  15. 05 5月, 2012 1 次提交
  16. 31 3月, 2012 1 次提交
  17. 28 2月, 2012 2 次提交
  18. 18 11月, 2011 1 次提交
    • H
      x86: Generate system call tables and unistd_*.h from tables · 303395ac
      H. Peter Anvin 提交于
      Generate system call tables and unistd_*.h automatically from the
      tables in arch/x86/syscalls.  All other information, like NR_syscalls,
      is auto-generated, some of which is in asm-offsets_*.c.
      
      This allows us to keep all the system call information in one place,
      and allows for kernel space and user space to see different
      information; this is currently used for the ia32 system call numbers
      when building the 64-bit kernel, but will be used by the x32 ABI in
      the near future.
      
      This also removes some gratuitious differences between i386, x86-64
      and ia32; in particular, now all system call tables are generated with
      the same mechanism.
      
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      303395ac
  19. 14 10月, 2010 1 次提交
  20. 14 9月, 2010 1 次提交
  21. 14 5月, 2010 1 次提交
  22. 17 2月, 2010 1 次提交
  23. 23 10月, 2009 1 次提交
  24. 20 9月, 2009 1 次提交
    • S
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      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>
      caa27b66
  25. 31 8月, 2009 1 次提交
  26. 27 8月, 2009 1 次提交
    • M
      x86: X86 instruction decoder build-time selftest · ca0e9bad
      Masami Hiramatsu 提交于
      Add a user-space selftest of x86 instruction decoder at kernel build
      time.
      When CONFIG_X86_DECODER_SELFTEST=y, Kbuild builds a test harness of x86
      instruction decoder and performs it after building vmlinux.
      The test compares the results of objdump and x86 instruction decoder
      code and check there are no differences.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      LKML-Reference: <20090813203421.31965.29006.stgit@localhost.localdomain>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      ca0e9bad
  27. 23 8月, 2009 1 次提交
  28. 04 8月, 2009 1 次提交
  29. 13 6月, 2009 1 次提交
  30. 18 4月, 2009 1 次提交
    • H
      x86, kbuild: make "make install" not depend on vmlinux · 1648e4f8
      H. Peter Anvin 提交于
      It is common to use "make install" in restricted environments which
      differ from the one which was actually used to build the kernel.  In
      such environments it is highly undesirable to trigger a rebuild of any
      part of the system.  Worse, the rebuild may be spurious, triggered by
      differences in the environment.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>
      1648e4f8
  31. 17 4月, 2009 1 次提交
  32. 13 3月, 2009 2 次提交
  33. 10 2月, 2009 1 次提交
    • T
      stackprotector: update make rules · 5d707e9c
      Tejun Heo 提交于
      Impact: no default -fno-stack-protector if stackp is enabled, cleanup
      
      Stackprotector make rules had the following problems.
      
      * cc support test and warning are scattered across makefile and
        kernel/panic.c.
      
      * -fno-stack-protector was always added regardless of configuration.
      
      Update such that cc support test and warning are contained in makefile
      and -fno-stack-protector is added iff stackp is turned off.  While at
      it, prepare for 32bit support.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5d707e9c
  34. 29 1月, 2009 2 次提交
  35. 23 10月, 2008 1 次提交
  36. 26 7月, 2008 1 次提交