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.
