Richard Weinberger wrote:
This patch is based on: https://lkml.org/lkml/2013/7/4/396
This is the original patch I sent across in July.
diff --git a/arch/um/Makefile b/arch/um/Makefile index 133f7de..5bc7892 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -8,6 +8,8 @@ ARCH_DIR := arch/um OS := $(shell uname -s) +OS_ARCH := $(shell uname -m) + # We require bash because the vmlinux link and loader script cpp use bash # features. SHELL := /bin/bash @@ -20,15 +22,14 @@ core-y += $(ARCH_DIR)/kernel/ \ MODE_INCLUDE += -I$(srctree)/$(ARCH_DIR)/include/shared/skas -HEADER_ARCH := $(SUBARCH) - -# Additional ARCH settings for x86 -ifeq ($(SUBARCH),i386) - HEADER_ARCH := x86 -endif -ifeq ($(SUBARCH),x86_64) - HEADER_ARCH := x86 - KBUILD_CFLAGS += -mcmodel=large +# Currently we support only i386 and x86_64, if you port UML to another arch +# add another if branch... +ifeq ($(OS_ARCH),x86_64) + HEADER_ARCH := x86 + KBUILD_DEFCONFIG := x86_64_defconfig +else + HEADER_ARCH := x86 + KBUILD_DEFCONFIG := i386_defconfig endif
I honestly don't get why this approach is superior to the original one. In the original, I could set SUBARCH to whatever target architecture and attempt to build user-mode Linux. Fact that it is only implemented for i386 and x86_64 aside, keeping a SUBARCH means that it's possible to build a 32-bit kernel on a 64-bit machine and vice-versa. If you want stuff to work automagically (ie. in the 90% case), you have to shell out to uname -m to figure out the host's real architecture. Which both versions do sufficiently well. Forget all that. What matters is that upstream is still broken, and users are suffering. Despite a reasonable fix being submitted in July. -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
