01 Dec, 2013

1 commit


17 Nov, 2013

1 commit

  • arch/um/defconfig only lists one default configuration, and that applies
    only to the i386 architecture. Replace it with two minimal
    configuration files generated using `make savedefconfig`:

    i386_defconfig and x86_64_defconfig

    The build scripts now require two updates:

    1. um's Kconfig (arch/x86/um/Kconfig) should specify an ARCH_DEFCONFIG
    section explicitly pointing to these scripts if the required
    variables are set. Take care to remove the DEFCONFIG_LIST section
    defined in the included file arch/um/Kconfig.common.

    2. um's Makefile (arch/um/Makefile) should set KBUILD_DEFCONFIG properly
    for the top-level Makefile to pick up. Copy the logic in
    arch/x86/Makefile to properly pick the defconfig file depending on
    the actual architecture; except we're working with $SUBARCH here,
    instead of $ARCH.

    Now, you can do:

    $ ARCH=um make defconfig
    $ ARCH=um make

    and successfully build User-Mode Linux on an x86_64 box in default
    configuration.

    Cc: Richard Weinberger
    Cc: Jeff Dike
    Signed-off-by: Ramkumar Ramachandra
    Signed-off-by: Richard Weinberger

    Ramkumar Ramachandra
     

03 Oct, 2012

1 commit

  • Partition the header include path flags into two sets, one for kernelspace
    builds and one for userspace builds.

    Add the following directories to build after the ordinary include directories
    so that #include will pick up the UAPI header directly if the kernel header
    has been moved there.

    The userspace set (represented by the USERINCLUDE make variable) contains:

    -I $(srctree)/arch/$(hdr-arch)/include/uapi
    -I arch/$(hdr-arch)/include/generated/uapi
    -I $(srctree)/include/uapi
    -I include/generated/uapi
    -include $(srctree)/include/linux/kconfig.h

    and the kernelspace set (represented by the LINUXINCLUDE make variable)
    contains:

    -I $(srctree)/arch/$(hdr-arch)/include
    -I arch/$(hdr-arch)/include/generated
    -I $(srctree)/include
    -I include --- if not building in the source tree

    plus everything in the USERINCLUDE set.

    Then use USERINCLUDE in building the x86 boot code.

    Signed-off-by: David Howells
    Acked-by: Arnd Bergmann
    Acked-by: Thomas Gleixner
    Acked-by: Paul E. McKenney
    Acked-by: Dave Jones

    David Howells
     

06 May, 2012

1 commit

  • Move the final link of vmlinux to a script to improve
    readability and maintainability of the code.

    The Makefile fragments used to link vmlinux has over the
    years seen far too many changes and the logic had become
    hard to follow.

    As the process by nature is serialized there was
    nothing gained including this in the Makefile.

    "um" has special link requirments - and the
    only way to handle this was to hard-code the linking
    of "um" in the script.
    This was better than trying to modularize it only for the
    benefit of "um" anyway.

    The shell script has been improved after input from:
    Arnaud Lacombe
    Nick Bowler

    Signed-off-by: Sam Ravnborg
    Cc: Arnaud Lacombe
    Cc: Nick Bowler
    Cc: Richard Weinberger
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

25 Mar, 2012

2 commits

  • x86_64 UML is unable to load modules if more than 504MiB
    of memory are used.
    This happens because on x86_64 the UML process has a quite high
    start address (typically around 0x6000000).
    If UML's memory is larger than 504MiB VMALLOC_START happens to be after
    0x8000000. This is no problem unless one loads a module which was built
    with R_X86_64_32S relocations.
    Symbols with a location > 0x8000000 cannot be used with R_X86_64_32S

    To deal with this x86_64 UML has to be compiled with -mcmodel=large
    such that no R_X86_64_32S relocations are used.

    Signed-off-by: Richard Weinberger
    Reported-by: 전하늘

    Richard Weinberger
     
  • Signed-off-by: Al Viro
    [richard@nod.at: Re-export SUBARCH in arch/um/Makefile]
    Signed-off-by: Richard Weinberger

    Al Viro
     

10 Dec, 2011

1 commit


06 Dec, 2011

2 commits


02 Nov, 2011

8 commits


15 Sep, 2011

1 commit

  • richard@nod.at:
    Fixes:
    /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libc.a(strrchr.o): In function `rindex':
    (.text+0x0): multiple definition of `strrchr'

    If both STATIC_LINK and UML_NET_VDE are set to "y" libc's strrchr may
    clash with the kernel implementation.

    This workaround comes originally from Jeff Dike:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494995#35

    Signed-off-by: Al Viro
    Signed-off-by: Richard Weinberger
    Cc: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Al Viro
     

12 Dec, 2009

1 commit

  • The simplest method was to add an extra asm-offsets.h
    file in arch/$ARCH/include/asm that references the generated file.

    We can now migrate the architectures one-by-one to reference
    the generated file direct - and when done we can delete the
    temporary arch/$ARCH/include/asm/asm-offsets.h file.

    Signed-off-by: Sam Ravnborg
    Cc: Al Viro
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

20 Sep, 2009

1 commit

  • Albin Tonnerre reported:

    Bash 4 filters out variables which contain a dot in them.
    This happends to be the case of CPPFLAGS_vmlinux.lds.
    This is rather unfortunate, as it now causes
    build failures when using SHELL=/bin/bash to compile,
    or when bash happens to be used by make (eg when it's /bin/sh)

    Remove the common definition of CPPFLAGS_vmlinux.lds by
    pushing relevant stuff to either Makefile.build or the
    arch specific kernel/Makefile where we build the linker script.

    This is also nice cleanup as we move the information out where
    it is used.

    Notes for the different architectures touched:

    arm - we use an already exported symbol
    cris - we use a config symbol aleady available
    [Not build tested]
    mips - the jiffies complexity has moved to vmlinux.lds.S where we need it.
    Added a few variables to CPPFLAGS - they are only used by
    the linker script.
    [Not build tested]
    powerpc - removed assignment that is not needed
    [not build tested]
    sparc - simplified it using $(BITS)
    um - introduced a few new exported variables to deal with this
    xtensa - added options to CPP invocation
    [not build tested]

    Cc: Albin Tonnerre
    Cc: Russell King
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: "David S. Miller"
    Cc: Jeff Dike
    Cc: Chris Zankel
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

06 Jan, 2009

1 commit

  • We need to make asm-offsets.h contents visible for objects built
    with userland headers. Instead of creating a symlink, just have the
    file with equivalent include (relative to location of header) created
    once. That kills the last symlink used in arch/um builds.

    Additionally, both generated headers can become dependencies of
    archprepare now, killing the misuse of prepare.

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

23 Oct, 2008

15 commits


08 Jul, 2008

1 commit

  • There are various constraints on the use of unit-at-a-time:
    - i386 uses no-unit-at-a-time for pre-4.0 (not 4.3)
    - x86_64 uses unit-at-a-time always

    Uli reported a crash on x86_64 with gcc 4.1.2 with unit-at-a-time,
    resulting in commit c0a18111e571138747a98af18b3a2124df56a0d1

    Ingo reported a gcc internal error with gcc 4.3 with no-unit-at-a-timem,
    resulting in 22eecde2f9034764a3fd095eecfa3adfb8ec9a98

    Benny Halevy is seeing extern inlines not resolved with gcc 4.3 with
    no-unit-at-a-time

    This patch reintroduces unit-at-a-time for gcc >= 4.0, bringing back the
    possibility of Uli's crash. If that happens, we'll debug it.

    I started seeing both the internal compiler errors and unresolved
    inlines on Fedora 9. This patch fixes both problems, without so far
    reintroducing the crash reported by Uli.

    Signed-off-by: Jeff Dike
    Cc: Benny Halevy
    Cc: Adrian Bunk
    Cc: Ingo Molnar
    Cc: Ulrich Drepper
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

07 May, 2008

1 commit

  • This reverts commit 22eecde2f9034764a3fd095eecfa3adfb8ec9a98. Uli
    reports that it breaks UML on x86-64 with the Fedora 8 gcc (gcc 4.1.2),
    causing a crash on startup. See

    http://marc.info/?l=linux-kernel&m=121011722806093&w=2

    for a trace.

    Reported-by: Ulrich Drepper
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 May, 2008

1 commit


09 Feb, 2008

1 commit

  • Calculate TASK_SIZE at run-time by figuring out the host's VMSPLIT - this is
    needed on i386 if UML is to run on hosts with varying VMSPLITs without
    recompilation.

    TASK_SIZE is now defined in terms of a variable, task_size. This gets rid of
    an include of pgtable.h from processor.h, which can cause include loops.

    On i386, task_size is calculated early in boot by probing the address space in
    a binary search to figure out where the boundary between usable and non-usable
    memory is. This tries to make sure that a page that is considered to be in
    userspace is, or can be made, read-write. I'm concerned about a system-global
    VDSO page in kernel memory being hit and considered to be a userspace page.

    On x86_64, task_size is just the old value of CONFIG_TOP_ADDR.

    A bunch of config variable are gone now. CONFIG_TOP_ADDR is directly replaced
    by TASK_SIZE. NEST_LEVEL is gone since the relocation of the stubs makes it
    irrelevant. All the HOST_VMSPLIT stuff is gone. All references to these in
    arch/um/Makefile are also gone.

    I noticed and fixed a missing extern in os.h when adding os_get_task_size.

    Note: This has been revised to fix the 32-bit UML on 64-bit host bug that
    Miklos ran into.

    Signed-off-by: Jeff Dike
    Cc: Miklos Szeredi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike