Eric Lee / smarc-fsl-linux-kernel

15 Jan, 2009

1 commit

  • 2ea038917   Revert "kbuild: strip generated symbols from *.ko" ... Browse Code »

    This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.

    And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
    9bb482476c6c9d1ae033306440c51ceac93ea80c

    These stripping patches has caused a set of issues:

    1) People have reported compatibility issues with binutils due to
    lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
    Reported by: Wenji
    2) ccache and distcc no longer works as expeced
    Reported by: Ted, Roland, + others
    3) The installed modules increased a lot in size
    Reported by: Ted, Davej + others

    Reported-by: Wenji Huang
    Reported-by: "Theodore Ts'o"
    Reported-by: Dave Jones
    Reported-by: Roland McGrath
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

20 Dec, 2008

1 commit

  • ad7a953c5   kbuild: strip generated symbols from *.ko ... Browse Code »

    This patch changes the way __crc_ symbols are being resolved from
    using ld to do so to using the assembler, thus allowing these symbols
    to be marked local (the linker creates then as global ones) and hence
    allow stripping (for modules) or ignoring (for vmlinux) them. While at
    this, also strip other generated symbols during module installation.

    One potentially debatable point is the handling of the flags passeed
    to gcc when translating the intermediate assembly file into an object:
    passing $(c_flags) unchanged doesn't work as gcc passes --gdwarf2 to
    gas whenever is sees any -g* option, even for -g0, and despite the
    fact that the compiler would have already produced all necessary debug
    info in the C->assembly translation phase. I took the approach of just
    filtering out all -g* options, but an alternative to such negative
    filtering might be to have a positive filter which might, in the ideal
    case allow just all the -Wa,* options to pass through.

    Signed-off-by: Jan Beulich
    Signed-off-by: Sam Ravnborg

    Jan Beulich
     

29 Jan, 2008

1 commit

  • 9b213118f   kbuild: fix installing external modules ... Browse Code »

    Eric Sandeen reported:
    Installing external modules is supposed to put them in some path
    under /lib/modules//extra/subdir/, but this change:
    http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=1.1982.9.23
    makes them go under /lib/modules//extrasubdir

    (for example, make M=fs/ext3 modules_install puts ext3.ko in
    /lib/modules//extrafs/ext3.ko)

    This was the case only when specifying a trailing slash to M=..

    Fixed by removing trailing slash if present so
    we correctly match dir part of target.

    Signed-off-by: Sam Ravnborg
    Cc: Eric Sandeen

    Sam Ravnborg
     

25 Jun, 2006

1 commit

  • ac031f26e   kbuild: add option for stripping modules while installing them ... Browse Code »

    Add option for stripping modules while installing them.

    This function adds support for stripping modules while they are being
    installed. CONFIG_DEBUG_KERNEL (which will probably become more
    popular as developers use kdump) causes the size of the installed
    modules to grow by a factor of 9 or so.

    Some kernel package systems solve this problem by stripping the debug
    information from /lib/modules after running "make modules_install",
    but that may not work for people who are installing directly into
    /lib/modules --- root partitions that were sized to handle 16 megs
    worth of modules may not be quite so happy with 145 megs of modules,
    so the "make modules_install" never succeeds.

    This patch allows such users to request modules_install to strip the
    modules as they are installed.

    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Sam Ravnborg

    Theodore Ts'o
     

06 Mar, 2006

1 commit

  • 4f1933620   kbuild: change kbuild to not rely on incorrect GNU make behavior ... Browse Code »

    The kbuild system takes advantage of an incorrect behavior in GNU make.
    Once this behavior is fixed, all files in the kernel rebuild every time,
    even if nothing has changed. This patch ensures kbuild works with both
    the incorrect and correct behaviors of GNU make.

    For more details on the incorrect behavior, see:

    http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html

    Changes in this patch:
    - Keep all targets that are to be marked .PHONY in a variable, PHONY.
    - Add .PHONY: $(PHONY) to mark them properly.
    - Remove any $(PHONY) files from the $? list when determining whether
    targets are up-to-date or not.

    Signed-off-by: Paul Smith
    Signed-off-by: Sam Ravnborg

    Paul Smith
     

26 Jul, 2005

1 commit

  • 8ec4b4ff1   kbuild: introduce Kbuild.include ... Browse Code »

    Kbuild.include is a placeholder for definitions originally present in
    both the top-level Makefile and scripts/Makefile.build.
    There were a slight difference in the filechk definition, so the most videly
    used version was kept and usr/Makefile was adopted for this syntax.

    Signed-off-by: Sam Ravnborg
    ---

    Sam Ravnborg
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds