29 Jan, 2008

9 commits


28 Jan, 2008

1 commit


25 Jan, 2008

1 commit


22 Jan, 2008

1 commit


16 Jan, 2008

1 commit


07 Jan, 2008

1 commit


21 Dec, 2007

1 commit


11 Dec, 2007

1 commit


09 Dec, 2007

2 commits

  • The check introduced in commit:
    4f1127e204377cbd2a56d112d323466f668e8334 "kbuild: fix
    infinite make recursion"

    caused certain external modules not to build and
    also caused 'make targz-pkg' to fail.
    This is a minimal fix so we revert to previous
    behaviour - but we do not overwrite the Makefile
    in the top-level directory.

    Signed-off-by: Sam Ravnborg
    Tested-by: Jay Cliburn
    Cc: Jay Cliburn

    Sam Ravnborg
     
  • Jan Altenberg reported that
    building with redirected input like this failed:
    make O=dir oldconfig bzImage < /dev/null

    The problem were caused by a make silentoldconfig being
    run before oldconfig and with a non-recent .config the build
    failed because silentoldconfig requires non-redirected stdin.

    Silentoldconfig was run as a side-effect of having the
    top-level Makefile re-made by make.
    Introducing an empty rule for the top-level Makefile
    (and Kbuild.include) fixed the issue.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

04 Dec, 2007

1 commit


18 Nov, 2007

1 commit

  • Simplify "make ARCH=x86" and fix kconfig so we again
    can set 64BIT in all.config.

    For a fix the diffstat is nice:
    6 files changed, 3 insertions(+), 36 deletions(-)

    The patch reverts these commits:
    0f855aa64b3f63d35a891510cf7db932a435c116
    -> kconfig: add helper to set config symbol from environment variable

    2a113281f5cd2febbab21a93c8943f8d3eece4d3
    -> kconfig: use $K64BIT to set 64BIT with all*config targets

    Roman Zippel pointed out that kconfig supported string
    compares so the additional complexity introduced by the
    above two patches were not needed.

    With this patch we have following behaviour:

    # make {allno,allyes,allmod,rand}config [ARCH=...]
    option \ host arch | 32bit | 64bit
    =====================================================
    ./. | 32bit | 64bit
    ARCH=x86 | 32bit | 32bit
    ARCH=i386 | 32bit | 32bit
    ARCH=x86_64 | 64bit | 64bit

    The general rule are that ARCH= and native architecture
    takes precedence over the configuration.
    So make ARCH=i386 [whatever] will always build a 32-bit
    kernel no matter what the configuration says.
    The configuration will be updated to 32-bit if it was
    configured to 64-bit and the other way around.

    This behaviour is consistent with previous behaviour so
    no suprises here.

    make ARCH=x86 will per default result in a 32-bit kernel
    but as the only ARCH= value x86 allow the user to select
    between 32-bit and 64-bit using menuconfig.

    Signed-off-by: Sam Ravnborg
    Cc: Roman Zippel
    Cc: Andreas Herrmann
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     

17 Nov, 2007

2 commits


13 Nov, 2007

2 commits

  • After unification of the Kconfig files and
    introducing K64BIT support in kconfig
    it required only trivial changes to enable
    "make ARCH=x86".

    With this patch you can build for x86_64 in several ways:
    1) make ARCH=x86_64
    2) make ARCH=x86 K64BIT=y
    3) make ARCH=x86 menuconfig
    => select 64-bit

    Likewise for i386 with the addition that
    i386 is default is you say ARCH=x86.

    Signed-off-by: Sam Ravnborg
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     
  • For x86 ARCH may say i386 or x86_64 and soon x86.
    Rely on CONFIG_X64_32 to select between 32/64 or just
    hardcode the value as appropriate.

    Signed-off-by: Sam Ravnborg
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"

    Sam Ravnborg
     

07 Nov, 2007

1 commit


05 Nov, 2007

1 commit

  • Too many people have CFLAGS set to support building userspace.
    And now Kbuild picks up CFLAGS this caused troubles.

    Although people should realise that setting CFLAGS has
    a 'global' effect the impact on the kernel build is a suprise.
    So change kbuild to pick up value from KCFLAGS that is
    much less used.

    When kbuild pick up a value it will warn like this:
    Makefile:544: "WARNING: Appending $KCFLAGS (-O3) from environment to kernel $CFLAGS"

    Signed-off-by: Sam Ravnborg
    Cc: Thomas Bächler
    Cc: David Miller
    Cc: Ingo Molnar

    Sam Ravnborg
     

02 Nov, 2007

1 commit

  • When configuring the kernel natively the uname matching is off,
    so fix up the uname mangling to get the proper SUBARCH. Needs
    an explicit range so that SH-5 doesn't break.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Paul Mundt

    Paul Mundt
     

26 Oct, 2007

1 commit


24 Oct, 2007

1 commit

  • The patch is big. Really big. You just won't believe how vastly hugely
    mindbogglingly big it is. I mean you may think it's a long way down the
    road to the chemist, but that's just peanuts to how big the patch from
    2.6.23 is.

    But it's all good.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

23 Oct, 2007

2 commits

  • depmod from module-init-tools 3.3-pre2 are reported
    to work fine in cross build.
    depmod from module-init-tools 3.1-pre5 are known to SEGV

    Do not workaround older module-init-tools bugs here.
    The right fix is for users to upgrade module-init-tools.

    Signed-off-by: Sam Ravnborg
    Cc: Geert Uytterhoeven

    Sam Ravnborg
     
  • make vmlinux would delete the content of $(MODVERDIR)
    equals .tmp_versions. This caused a subsequent
    make modules_install to fail.

    Fix it so we clean the directory only for the
    modules build - but we still unconditionally create it so
    we can do:
    make dir/file.ko
    without a preceeding make modules.

    Reported by David Miller

    Signed-off-by: Sam Ravnborg
    Cc: David Miller

    Sam Ravnborg
     

21 Oct, 2007

1 commit


20 Oct, 2007

3 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild:
    kbuild: fix first module build
    kconfig: update kconfig-language text
    kbuild: introduce cc-cross-prefix
    kbuild: disable depmod in cross-compile kernel build
    kbuild: make deb-pkg - add 'Provides:' line
    kconfig: comment typo in scripts/kconfig/Makefile.
    kbuild: stop docproc segfaulting when SRCTREE isn't set.
    kbuild: modpost problem when symbols move from one module to another
    kbuild: cscope - filter out .tmp_* in find_sources
    kbuild: mailing list has moved
    kbuild: check asm symlink when building a kernel

    Linus Torvalds
     
  • When building a specific module before doing a total kernel
    build it failed because $(MORVERDIR) were missing.
    Creating the MODVERDIR explicit (independent of KBUILD_MODULES)
    fixed this. As a side-effect the MODVERDIR will be created
    also for a non-module build - but no harm done by that.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • Begin infrastructure for kernel code samples in the samples/ directory.
    Add its Kconfig and Kbuild files.
    Source its Kconfig file in all arch/ Kconfigs.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathieu Desnoyers
     

19 Oct, 2007

1 commit

  • When building embedded systems in a cross-compile environment and
    populating a target's file system image, we don't want to run the
    depmod on the host as we may be building for a completely different
    architecture. Since there's no such thing as a cross-depmod, we
    just disable running depmod in the cross-compile case and we just
    run depmod on the target at bootup.

    Inspired by patches from Christian, Armin and Deepak.

    This solves: http://bugzilla.kernel.org/show_bug.cgi?id=3881

    Signed-off-by: Sam Ravnborg
    Cc: Christian Bjølevik
    Cc: Deepak Saxena and
    Cc: Armin Kuster ,

    Sam Ravnborg
     

18 Oct, 2007

3 commits

  • remove .tmp_kallsyms*.S in cscope.files

    Signed-off-by: Yinghai Lu
    Signed-off-by: Sam Ravnborg

    Yinghai Lu
     
  • We often hit the situation where the asm symlink
    in include/ points to the wrong architecture.
    In 9 out of 10 cases thats because we forgot to set
    ARCH but sometimes we just reused the same tree
    for another ARCH. For the merged x86 tree we need
    to create a new symlink but this is not obvious.
    So with the following patch we check if the symlink
    points to the correct architecture and error
    out if this is not the case.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     
  • otherwise get the two copy file list in SRCARCH

    for cscope:
    C symbol: start_kernel

    File Function Line
    0 proto.h 11 extern void start_kernel(void );
    1 start_kernel.h 10 extern asmlinkage void __init start_kernel(void );
    2 head32.c i386_start_kernel 37 start_kernel();
    3 head32.c i386_start_kernel 37 start_kernel();
    4 head64.c x86_64_start_kernel 85 start_kernel();
    5 head64.c x86_64_start_kernel 85 start_kernel();
    6 head_32.S options 199 cmpb $0,%cl #the first CPU calls start_kernel
    7 head_32.S options 199 cmpb $0,%cl #the first CPU calls start_kernel
    8 enlighten.c xen_start_kernel 1145 start_kernel();
    9 enlighten.c xen_start_kernel 1145 start_kernel();
    a lguest.c lguest_init 1095 start_kernel();
    b main.c start_kernel 513 asmlinkage void __init start_kernel(void )

    after the patch:
    C symbol: start_kernel

    File Function Line
    0 proto.h 11 extern void start_kernel(void );
    1 start_kernel.h 10 extern asmlinkage void __init start_kernel(void );
    2 head32.c i386_start_kernel 37 start_kernel();
    3 head64.c x86_64_start_kernel 85 start_kernel();
    4 head_32.S options 199 cmpb $0,%cl #the first CPU calls start_kernel
    5 enlighten.c xen_start_kernel 1145 start_kernel();
    6 lguest.c lguest_init 1095 start_kernel();
    7 main.c start_kernel 513 asmlinkage void __init start_kernel(void )

    Signed-off-by: Yinghai Lu
    Signed-off-by: Thomas Gleixner

    Yinghai Lu
     

16 Oct, 2007

1 commit

  • The variable CPPFLAGS is a wellknown variable and the usage by
    kbuild may result in unexpected behaviour.

    This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the
    tree and enabling one to use:
    make CPPFLAGS=...
    to specify additional CPP commandline options.

    Patch was tested on following architectures:
    alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg