An error occurred fetching the project authors.
  1. 18 Jun, 2010 1 commit
    • Michal Marek's avatar
      kbuild: Clean up and speed up the localversion logic · 09155120
      Michal Marek authored
      Now that we run scripts/setlocalversion during every build, it makes
      sense to move all the localversion logic there. This cleans up the
      toplevel Makefile and also makes sure that the script is called only
      once in 'make prepare' (previously, it would be called every time due to
      a variable expansion in an ifneq statement). No user-visible change is
      intended, unless one runs the setlocalversion script directly.
      Reported-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      09155120
  2. 06 May, 2010 1 commit
  3. 10 Mar, 2010 1 commit
  4. 08 Mar, 2010 1 commit
  5. 05 Feb, 2010 1 commit
  6. 02 Feb, 2010 3 commits
    • Joe Perches's avatar
    • David Rientjes's avatar
      kbuild: improve version string logic · 85a256d8
      David Rientjes authored
      The LOCALVERSION= string passed to "make" will now always be appended to
      the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
      whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
      uniquely identify their kernel builds with a string.
      
      If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
      setlocalversion (or .scmversion) is appended to the kernel version, if it
      exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
      to the kernel version to represent that the kernel has been revised since
      the last release unless "make LOCALVERSION=" was used to uniquely identify
      the build.
      
      The end result is this:
      
       - when LOCALVERSION= is passed to "make", it is appended to the kernel
         version,
      
       - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
         appended if the respository has been revised beyond a tagged commit,
         and
      
       - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
         repository has been revised beyond a tagged commit and LOCALVERSION=
         was not passed to "make".
      
      Examples:
      
      With CONFIG_LOCALVERSION_AUTO: "make" results in
      v2.6.32-rc4-00149-ga3ccf63e.  If there are uncommited changes to the
      respository, it results in v2.6.32-rc4-00149-ga3ccf63e-dirty.  If
      "make LOCALVERSION=kbuild" were used, it results in
      v2.6.32-rc4-kbuild-00149-ga3ccf63e-dirty.
      
      Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
      unless the repository is at the Linux v2.6.32-rc4 commit (in which
      case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
      were used, it results in v2.6.32-rc4-kbuild.
      
      Also renames variables such as localver-auto and _localver-auto to more
      accurately describe what they represent: localver-extra and
      scm-identifier, respectively.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      85a256d8
    • Roland McGrath's avatar
      kconfig CROSS_COMPILE option · 84336466
      Roland McGrath authored
      This adds CROSS_COMPILE as a kconfig string so you can store it in
      .config.  Then you can use plain "make" in the configured kernel build
      directory to do the right cross compilation without setting the
      command-line or environment variable every time.
      
      With this, you can set up different build directories for different kernel
      configurations, whether native or cross-builds, and then use the simple:
      
      	make -C /build/dir M=module-source-dir
      
      idiom to build modules for any given target kernel, indicating which one
      by nothing but the build directory chosen.
      
      I tried a version that defaults the string with env="CROSS_COMPILE" so
      that in a "make oldconfig" with CROSS_COMPILE in the environment you can
      just hit return to store the way you're building it.  But the kconfig
      prompt for strings doesn't give you any way to say you want an empty
      string instead of the default, so I punted that.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Anibal Monsalve Salazar <anibal@debian.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      84336466
  7. 29 Jan, 2010 1 commit
  8. 21 Jan, 2010 1 commit
  9. 13 Jan, 2010 2 commits
  10. 06 Jan, 2010 1 commit
  11. 24 Dec, 2009 1 commit
  12. 18 Dec, 2009 1 commit
  13. 17 Dec, 2009 2 commits
  14. 12 Dec, 2009 12 commits
  15. 03 Dec, 2009 1 commit
  16. 19 Nov, 2009 1 commit
  17. 17 Nov, 2009 1 commit
    • Steven Rostedt's avatar
      tracing: Only print objcopy version warning once from recordmcount · 638adb05
      Steven Rostedt authored
      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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      638adb05
  18. 15 Nov, 2009 1 commit
  19. 13 Nov, 2009 1 commit
  20. 03 Nov, 2009 1 commit
  21. 16 Oct, 2009 1 commit
  22. 11 Oct, 2009 2 commits
    • Linus Torvalds's avatar
      Linux 2.6.32-rc4 · 16129139
      Linus Torvalds authored
      16129139
    • Sam Ravnborg's avatar
      kbuild: revert "save ARCH & CROSS_COMPILE ..." · 2331d1a6
      Sam Ravnborg authored
      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: default avatarSam 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>
      2331d1a6
  23. 05 Oct, 2009 1 commit
    • Linus Torvalds's avatar
      Linux 2.6.32-rc3 · 374576a8
      Linus Torvalds authored
      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.
      374576a8
  24. 27 Sep, 2009 1 commit