10 Jan, 2009

1 commit

  • Kernels that don't support ELF coredumps at all surely can't be supporting
    new partial-segment flavored ELF coredumps ... don't make folk answer
    Kconfig questions about that flavor.

    Signed-off-by: David Brownell
    Acked-by: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

20 Oct, 2008

1 commit

  • This adds a kconfig option to change the /proc/PID/coredump_filter default.
    Fedora has been carrying a trivial patch to change the hard-wired value for
    this default, since Fedora 8. The default default can't change safely
    because there are old GDB versions out there (all before 6.7) that are
    confused by the core dump files created by the MMF_DUMP_ELF_HEADERS setting.

    Signed-off-by: Roland McGrath
    Cc: Michael Kerrisk
    Cc: Oleg Nesterov
    Cc: Alan Cox
    Cc: Andi Kleen
    Cc: KOSAKI Motohiro
    Cc: Kawai Hidehiro
    Cc: Ingo Molnar
    Cc: David Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roland McGrath
     

17 Oct, 2008

1 commit


07 Sep, 2008

2 commits


28 Jul, 2008

1 commit


07 Jun, 2008

1 commit

  • Fix the following compile error:

    CC fs/binfmt_flat.o
    In file included from
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:36:
    /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/flat.h:14:22: error: asm/flat.h: No such file or directory
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c: In function 'create_flat_tables':
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:124: error: implicit declaration of function 'flat_stack_align'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:125: error: implicit declaration of function 'flat_argvp_envp_on_stack'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c: In function 'calc_reloc':
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:347: error: implicit declaration of function 'flat_reloc_valid'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c: In function 'load_flat_file':
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:479: error: implicit declaration of function 'flat_old_ram_flag'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:755: error: implicit declaration of function 'flat_set_persistent'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:757: error: implicit declaration of function 'flat_get_relocate_addr'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:765: error: implicit declaration of function 'flat_get_addr_from_rp'
    /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:781: error: implicit declaration of function 'flat_put_addr_at_rp'

    Reported-by: Adrian Bunk
    Signed-off-by: Adrian Bunk
    Tested-by: David Howells
    Acked-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

29 Apr, 2008

1 commit

  • I have not yet seen anyone saying he has a reasonable use case for using
    BINFMT_FLAT modular on his embedded device.

    Considering that fs/binfmt_flat.c even lacks a MODULE_LICENSE() I really doubt
    there is any, and this patch therefore makes BINFMT_FLAT a bool.

    Signed-off-by: Adrian Bunk
    Acked-by: Bryan Wu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

22 Apr, 2008

1 commit


09 Feb, 2008

1 commit

  • Suppress A.OUT library support if CONFIG_ARCH_SUPPORTS_AOUT is not set.

    Not all architectures support the A.OUT binfmt, so the ELF binfmt should not
    be permitted to go looking for A.OUT libraries to load in such a case. Not
    only that, but under such conditions A.OUT core dumps are not produced either.

    To make this work, this patch also does the following:

    (1) Makes the existence of the contents of linux/a.out.h contingent on
    CONFIG_ARCH_SUPPORTS_AOUT.

    (2) Renames dump_thread() to aout_dump_thread() as it's only called by A.OUT
    core dumping code.

    (3) Moves aout_dump_thread() into asm/a.out-core.h and makes it inline. This
    is then included only where needed. This means that this bit of arch
    code will be stored in the appropriate A.OUT binfmt module rather than
    the core kernel.

    (4) Drops A.OUT support for Blackfin (according to Mike Frysinger it's not
    needed) and FRV.

    This patch depends on the previous patch to move STACK_TOP[_MAX] out of
    asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT
    format is available.

    [jdike@addtoit.com: uml: re-remove accidentally restored code]
    Signed-off-by: David Howells
    Cc:
    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

30 Jan, 2008

1 commit

  • This adds Kconfig and Makefile bits to build fs/compat_binfmt_elf.c,
    just added. Each arch that wants to use this file needs to add a
    "select COMPAT_BINFMT_ELF" line in its Kconfig bits that enable COMPAT.

    Signed-off-by: Roland McGrath
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Roland McGrath
     

21 May, 2007

1 commit

  • Not really sure where this bogosity came from, but there's certainly
    nothing special about sh that lets us use flat files with the MMU on.

    Kill the dependency, and leave it as !MMU, like it is for all of the
    other nommu-wielding ports.

    Signed-off-by: Paul Mundt

    Paul Mundt
     

08 May, 2007

1 commit

  • This adds support for the Analog Devices Blackfin processor architecture, and
    currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561
    (Dual Core) devices, with a variety of development platforms including those
    avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP,
    BF561-EZKIT), and Bluetechnix! Tinyboards.

    The Blackfin architecture was jointly developed by Intel and Analog Devices
    Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in
    December of 2000. Since then ADI has put this core into its Blackfin
    processor family of devices. The Blackfin core has the advantages of a clean,
    orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC
    (Multiply/Accumulate), state-of-the-art signal processing engine and
    single-instruction, multiple-data (SIMD) multimedia capabilities into a single
    instruction-set architecture.

    The Blackfin architecture, including the instruction set, is described by the
    ADSP-BF53x/BF56x Blackfin Processor Programming Reference
    http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf

    The Blackfin processor is already supported by major releases of gcc, and
    there are binary and source rpms/tarballs for many architectures at:
    http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete
    documentation, including "getting started" guides available at:
    http://docs.blackfin.uclinux.org/ which provides links to the sources and
    patches you will need in order to set up a cross-compiling environment for
    bfin-linux-uclibc

    This patch, as well as the other patches (toolchain, distribution,
    uClibc) are actively supported by Analog Devices Inc, at:
    http://blackfin.uclinux.org/

    We have tested this on LTP, and our test plan (including pass/fails) can
    be found at:
    http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel

    [m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files]
    Signed-off-by: Bryan Wu
    Signed-off-by: Mariusz Kozlowski
    Signed-off-by: Aubrey Li
    Signed-off-by: Jie Zhang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bryan Wu
     

09 Jan, 2006

1 commit


31 Oct, 2005

1 commit

  • Add CONFIG_X86_32 for i386. This allows selecting options that only apply
    to 32-bit systems.

    (X86 && !X86_64) becomes X86_32
    (X86 || X86_64) becomes X86

    Signed-off-by: Brian Gerst
    Cc: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Brian Gerst
     

17 Apr, 2005

1 commit

  • 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