1. 03 7月, 2013 1 次提交
  2. 01 7月, 2013 1 次提交
  3. 28 6月, 2013 1 次提交
  4. 24 6月, 2013 1 次提交
    • M
      kbuild: fix error when building from src rpm · c398ff00
      Mike Marciniszyn 提交于
      The following issue can be reproduced with Linus' tree on
      an x86_64 server.
      
      >+ cp /home/user/rpmbuild-test/BUILDROOT/kernel-3.9.2.x86_64/boot/vmlinuz-3.9.2
      >cp: missing destination file operand after
      >/home/user/rpmbuild-test/BUILDROOT/kernel-3.9.2-1.x86_64/boot/vmlinuz-3.9.2'
      >Try `cp --help' for more information.
      >error: Bad exit status from /var/tmp/rpm-tmp.R4o0iI (%install)
      
      Here are the commands to reproduce:
      
      make defconfig
      make rpm-pkg
      
      Use the resulting src rpm to build as follows:
      
      mkdir ~/rpmbuild-test
      cd ~/rpmbuild-test
      rpmbuild --rebuild --define "_topdir `pwd`" -vv ~/rpmbuild/SRPMS/kernel-3.10.0_rc1+-1.src.rpm
      
      The issue is because the %install script uses $KBUILD_IMAGE and it hasn't
      been set since it is only available in the kbuild system and not in the
      %install script.
      
      This patch adds a Makefile target to emit the image_name that can be used
      and modifies the mkspec to use the dynamic name in %install.
      Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      c398ff00
  5. 23 6月, 2013 1 次提交
  6. 16 6月, 2013 1 次提交
  7. 09 6月, 2013 1 次提交
  8. 02 6月, 2013 1 次提交
  9. 27 5月, 2013 1 次提交
  10. 21 5月, 2013 1 次提交
  11. 12 5月, 2013 1 次提交
  12. 29 4月, 2013 2 次提交
    • A
      Turn off -Wmaybe-uninitialized when building with -Os · e74fc973
      Arnd Bergmann 提交于
      gcc-4.7 and higher add a lot of false positive warnings about
      potential uses of uninitialized warnings, but only when optimizing
      for size (-Os). This is the default when building allyesconfig,
      which turns on CONFIG_CC_OPTIMIZE_FOR_SIZE.
      
      In order to avoid getting a lot of patches that initialize such
      variables and accidentally hide real errors along the way, let's
      just turn off this warning on the respective gcc versions
      when building with size optimizations. The -Wmaybe-uninitialized
      option was introduced in the same gcc version (4.7) that is now
      causing the false positives, so there is no effect on older compilers.
      
      A side effect is that when building with CONFIG_CC_OPTIMIZE_FOR_SIZE,
      we might now see /fewer/ warnings about possibly uninitialized
      warnings than with -O2, but that is still much better than seeing
      warnings known to be bogus.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e74fc973
    • L
      Linux 3.9 · c1be5a5b
      Linus Torvalds 提交于
      c1be5a5b
  13. 22 4月, 2013 1 次提交
  14. 18 4月, 2013 1 次提交
    • M
      rpm-pkg: Do not package the whole source directory · 6615d6c3
      Michal Marek 提交于
      The source tree can contain lots of uninteresting data like tag or
      cscope files, packaging which slows down make rpm needlessly. It can
      also break the build, if the tree contains an unrelated file named
      *.spec. The downside of this change is that new subdirectories have to
      be added to the KBUILD_ALLDIRS variable in the top-level Makefile. The
      upside is that the behavior is more predictable.
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      6615d6c3
  15. 15 4月, 2013 1 次提交
  16. 10 4月, 2013 1 次提交
  17. 08 4月, 2013 1 次提交
  18. 01 4月, 2013 1 次提交
  19. 24 3月, 2013 1 次提交
  20. 18 3月, 2013 1 次提交
  21. 16 3月, 2013 1 次提交
  22. 15 3月, 2013 1 次提交
    • R
      CONFIG_SYMBOL_PREFIX: cleanup. · b92021b0
      Rusty Russell 提交于
      We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
      "_".  But Al Viro broke this in "consolidate cond_syscall and
      SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
      do so.
      
      Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
      prefix it so something.  So various places define helpers which are
      defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
      
      1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
      2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
      3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
      4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
      5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
      6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
      7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
         CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
         for pasting.
      
      (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
      
      Let's solve this properly:
      1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
      2) Make linux/export.h usable from asm.
      3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
      4) Make everyone use them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: James Hogan <james.hogan@imgtec.com> (metag)
      b92021b0
  23. 11 3月, 2013 1 次提交
  24. 04 3月, 2013 1 次提交
  25. 22 2月, 2013 2 次提交
    • A
      Kbuild: Disable var tracking with CONFIG_DEBUG_INFO_REDUCED · e82c4bb8
      Andi Kleen 提交于
      Newer gcc enables the var-tracking pass with -g to keep track which
      registers contain which variables. This is one of the slower passes in gcc.
      
      With reduced debug info (aimed at objdump -S, but not using a full debugger)
      we don't need this fine grained tracking. But it was still enabled
      because -g was enabled. Disable it explicitely for DEBUG_INFO_REDUCED.
      
      On my 8T workstation this gives me about a 12 second gain in building
      a reasonable kernel config (2min16 vs 2min28) with DEBUG_INFO_REDUCED.
      With full DEBUG_INFO it takes 2min46
      
      The actual improvement in user time taken by the compiler is much higher
      (all CPU combined user time 15min5s vs 16m30 before)
      but the usual amdahl bottleneck on the linker prevents more speedup.
      It still saves some more energy and keeps cycles for other things.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e82c4bb8
    • J
      depmod: pass -P $CONFIG_SYMBOL_PREFIX · 8937e897
      James Hogan 提交于
      On architectures which have symbol prefixes, depmod emits lots of
      warnings like this:
      
      WARNING: $module.ko needs unknown symbol $symbol
      
      This is because depmod isn't being passed the -P <symbol_prefix>
      arguments to specify the symbol prefix to ignore. This option is
      included since the 3.13 release of module-init-tools.
      
      Update scripts/depmod.sh to take extra arguments for the symbol prefix
      (required but may be empty), and update the main Makefile to always pass
      "$(CONFIG_SYMBOL_PREFIX)" to scripts/depmod.sh.
      
      If the provided symbol prefix is non-empty, scripts/depmod.sh checks if
      depmod --version reports module-init-tools with a version number < 3.13
      otherwise it appends -P $SYMBOL_PREFIX to the depmod command line.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: linux-kbuild@vger.kernel.org
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: uclinux-dist-devel@blackfin.uclinux.org
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      8937e897
  26. 19 2月, 2013 1 次提交
  27. 09 2月, 2013 1 次提交
  28. 01 2月, 2013 1 次提交
  29. 26 1月, 2013 1 次提交
  30. 25 1月, 2013 3 次提交
  31. 23 1月, 2013 1 次提交
  32. 18 1月, 2013 1 次提交
  33. 10 1月, 2013 1 次提交
  34. 03 1月, 2013 1 次提交
  35. 22 12月, 2012 1 次提交
  36. 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