Message ID | 1377073172-3662-3-git-send-email-richard@nod.at (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 12:40, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: > Forget all that. What matters is that upstream is still broken, and > users are suffering. Despite a reasonable fix being submitted in July. So, what exactly is broken in upstream? make defconfig works as it always did. make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a defconfig for 32bit. make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Weinberger wrote: > So, what exactly is broken in upstream? > make defconfig works as it always did. Auto-detection of SUBARCH, which can be done with a simple call to uname -m (the 90% case). The second patch I submitted prevented spawning xterms unnecessarily, which we discussed was a good move. > make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a defconfig for 32bit. > make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. Yes, that's how I prepared the patch in the first place. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 12:53, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> So, what exactly is broken in upstream? >> make defconfig works as it always did. > > Auto-detection of SUBARCH, which can be done with a simple call to > uname -m (the 90% case). The second patch I submitted prevented > spawning xterms unnecessarily, which we discussed was a good move. Covering only 90% of all cases is not enough. We must not break existing setups. That's also why my "Get rid of SUBARCH" series is not upstream. Your second patch changed CONFIG_CON_CHAN to pts, which is ok but not a major issue. The xterms are also not spawning unnecessarily they spawn upon a tty device is opened. With your patch UML create another pts. Thus, the spawning is hidden... I did not push it upstream because it depended on your first one and as I said, it's not critical. This does not mean that I moved it to /dev/null. Again, the plan is to get rid of SUBARCH at all. >> make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a defconfig for 32bit. >> make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. > > Yes, that's how I prepared the patch in the first place. So, nothing is broken. If you want "make defconfig ARCH=um" creating a defconfig for the correct arch you need more than your first patch. Again, "Get rid of SUBARCH" series has the same goal. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Weinberger wrote: >> Auto-detection of SUBARCH, which can be done with a simple call to >> uname -m (the 90% case). The second patch I submitted prevented >> spawning xterms unnecessarily, which we discussed was a good move. > > Covering only 90% of all cases is not enough. > We must not break existing setups. > That's also why my "Get rid of SUBARCH" series is not upstream. Mine covers 100% of the cases. My series is about auto-detection of SUBARCH, not its removal: you can still set a SUBARCH from the command-line; existing setups don't break. > Your second patch changed CONFIG_CON_CHAN to pts, which is ok but not > a major issue. "Major" or "minor" is purely your classification: don't impose your value judgement on reasonable patches. I am the user, and I demand a pleasant build process and ui. Moreover, how do you expect more contributions to come in until existing patches make it to upstream? > The xterms are also not spawning unnecessarily they spawn upon a tty device is opened. > With your patch UML create another pts. Thus, the spawning is hidden... It connects to an existing host pts device instead of spawning a new xterm and connecting to the console io on that. Why is that not desirable? > I did not push it upstream because it depended on your first one and as I said, it's not critical. > This does not mean that I moved it to /dev/null. ... and you still haven't told me what's wrong with my first patch. > Again, the plan is to get rid of SUBARCH at all. You've been harping about this plan for the last N months, and nothing has happened so far. It's time to stop planning, and accept good work. >>> make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a defconfig for 32bit. >>> make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. >> >> Yes, that's how I prepared the patch in the first place. > > So, nothing is broken. So the user is Ugly and Stupid for expecting: $ make defconfig ARCH=um $ make -j 8 ARCH=um to work? Stop denying problems, no matter how "major" or "minor" they are. > If you want "make defconfig ARCH=um" creating a defconfig for the correct arch you need > more than your first patch. No, you don't. Try it for yourself and see. Set a SUBARCH if you like, and it'll still work fine. > Again, "Get rid of SUBARCH" series has the same goal. For the last time, getting rid of SUBARCH is Wrong and Undesirable. -- 8< -- Here's a transcript spoonfeeding you the impact of my first patch: $ make defconfig ARCH=um SUBARCH=i386 *** Default configuration is based on 'i386_defconfig' # # configuration written to .config # $ make defconfig ARCH=um SUBARCH=x86_64 *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # $ make defconfig ARCH=um *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # In the last case, notice how defconfig automatically picks up x86_64_defconfig correctly: if I were on an i386 machine, it would have picked up i386_defconfig like in the first case. Without my patch, the last case would have incorrectly picked up an i386 defconfig, which is Stupid and Wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 13:43, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >>> Auto-detection of SUBARCH, which can be done with a simple call to >>> uname -m (the 90% case). The second patch I submitted prevented >>> spawning xterms unnecessarily, which we discussed was a good move. >> >> Covering only 90% of all cases is not enough. >> We must not break existing setups. >> That's also why my "Get rid of SUBARCH" series is not upstream. > > Mine covers 100% of the cases. My series is about auto-detection of > SUBARCH, not its removal: you can still set a SUBARCH from the > command-line; existing setups don't break. I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously create a x86_64 config on x86_64. This breaks existing setups. >> Your second patch changed CONFIG_CON_CHAN to pts, which is ok but not >> a major issue. > > "Major" or "minor" is purely your classification: don't impose your > value judgement on reasonable patches. I am the user, and I demand a > pleasant build process and ui. Moreover, how do you expect more > contributions to come in until existing patches make it to upstream? > >> The xterms are also not spawning unnecessarily they spawn upon a tty device is opened. >> With your patch UML create another pts. Thus, the spawning is hidden... > > It connects to an existing host pts device instead of spawning a new > xterm and connecting to the console io on that. Why is that not > desirable? > >> I did not push it upstream because it depended on your first one and as I said, it's not critical. >> This does not mean that I moved it to /dev/null. > > ... and you still haven't told me what's wrong with my first patch. > >> Again, the plan is to get rid of SUBARCH at all. > > You've been harping about this plan for the last N months, and nothing > has happened so far. It's time to stop planning, and accept good work. I sent the series on Aug 21st. Do the maths, it's not N months... >>>> make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a defconfig for 32bit. >>>> make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. >>> >>> Yes, that's how I prepared the patch in the first place. >> >> So, nothing is broken. > > So the user is Ugly and Stupid for expecting: > > $ " > $ make -j 8 ARCH=um > > to work? Stop denying problems, no matter how "major" or "minor" they are. "make defconfig ARCH=um" creates a defconfig for x86 as it always did. If you want to run a x86_64 bit user space, create a x86_64 defconfig. >> If you want "make defconfig ARCH=um" creating a defconfig for the correct arch you need >> more than your first patch. > > No, you don't. Try it for yourself and see. Set a SUBARCH if you like, > and it'll still work fine. > >> Again, "Get rid of SUBARCH" series has the same goal. > > For the last time, getting rid of SUBARCH is Wrong and Undesirable. That's your opinion. > -- 8< -- > Here's a transcript spoonfeeding you the impact of my first patch: > > $ make defconfig ARCH=um SUBARCH=i386 > *** Default configuration is based on 'i386_defconfig' > # > # configuration written to .config > # > $ make defconfig ARCH=um SUBARCH=x86_64 > *** Default configuration is based on 'x86_64_defconfig' > # > # configuration written to .config > # > $ make defconfig ARCH=um > *** Default configuration is based on 'x86_64_defconfig' > # > # configuration written to .config > # > > In the last case, notice how defconfig automatically picks up > x86_64_defconfig correctly: if I were on an i386 machine, it would > have picked up i386_defconfig like in the first case. Without my > patch, the last case would have incorrectly picked up an i386 > defconfig, which is Stupid and Wrong. You missed SUBARCH=x86. That said, if you cover all cases I'll happily merge that. And honestly, your patches are minor stuff, they don't even touch C source files. Acting up like you do just because of some default values is crazy. We have more serious problems so solve. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Weinberger wrote: > I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously > create a x86_64 config on x86_64. > This breaks existing setups. I'll fix this and resubmit soon. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ramkumar Ramachandra wrote: > Richard Weinberger wrote: >> I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously >> create a x86_64 config on x86_64. >> This breaks existing setups. > > I'll fix this and resubmit soon. Wait a minute. You're now arguing about whether the generic "x86" means i386 or x86_64. Its meaning is already defined in arch/x86/Kconfig and arch/x86/um/Kconfig: see the config 64BIT. Unless i386 is explicitly specified, the default is to build a 64-bit kernel. That is already defined for a normal Linux kernel, and user-mode Linux should not break that convention. So, in the example you pulled out of your hat: $ make defconfig ARCH=um SUBARCH=x86 the user should expect a 64-bit build, and not an i386 build as you say. Both my patches are correct, and the "regression" that you pointed out is a red herring. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 26, 2013 at 3:13 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote: > Ramkumar Ramachandra wrote: >> Richard Weinberger wrote: >>> I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously >>> create a x86_64 config on x86_64. >>> This breaks existing setups. >> >> I'll fix this and resubmit soon. > > Wait a minute. You're now arguing about whether the generic "x86" > means i386 or x86_64. Its meaning is already defined in > arch/x86/Kconfig and arch/x86/um/Kconfig: see the config 64BIT. Unless > i386 is explicitly specified, the default is to build a 64-bit kernel. > That is already defined for a normal Linux kernel, and user-mode Linux > should not break that convention. So, in the example you pulled out of > your hat: > > $ make defconfig ARCH=um SUBARCH=x86 > > the user should expect a 64-bit build, and not an i386 build as you > say. Both my patches are correct, and the "regression" that you > pointed out is a red herring. Sorry for chiming in, but... what about cross compiling? SUBARCH=x86 should give you a 32-bit ia32 kernel, right? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven wrote: > Sorry for chiming in, but... what about cross compiling? > SUBARCH=x86 should give you a 32-bit ia32 kernel, right? User-Mode Linux only supports two host architectures (called $SUBARCH) at the moment: i386 and x86_64. If you leave out the $SUBARCH on either an i386 or x86_64 machine, my patch will automatically pick the $(uname -m) architecture to build with. To cross-compile, specify the $SUBARCH explicitly. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 15:26, schrieb Geert Uytterhoeven: > On Thu, Sep 26, 2013 at 3:13 PM, Ramkumar Ramachandra > <artagnon@gmail.com> wrote: >> Ramkumar Ramachandra wrote: >>> Richard Weinberger wrote: >>>> I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously >>>> create a x86_64 config on x86_64. >>>> This breaks existing setups. >>> >>> I'll fix this and resubmit soon. >> >> Wait a minute. You're now arguing about whether the generic "x86" >> means i386 or x86_64. Its meaning is already defined in >> arch/x86/Kconfig and arch/x86/um/Kconfig: see the config 64BIT. Unless >> i386 is explicitly specified, the default is to build a 64-bit kernel. >> That is already defined for a normal Linux kernel, and user-mode Linux >> should not break that convention. So, in the example you pulled out of >> your hat: >> >> $ make defconfig ARCH=um SUBARCH=x86 >> >> the user should expect a 64-bit build, and not an i386 build as you >> say. Both my patches are correct, and the "regression" that you >> pointed out is a red herring. > > Sorry for chiming in, but... what about cross compiling? > SUBARCH=x86 should give you a 32-bit ia32 kernel, right? Correct. Users expect from SUBARCH=x86 a i386 32bit UML kernel. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Weinberger wrote: >> Sorry for chiming in, but... what about cross compiling? >> SUBARCH=x86 should give you a 32-bit ia32 kernel, right? > > Correct. > Users expect from SUBARCH=x86 a i386 32bit UML kernel. This is an insane expectation. This is kernel convention (it has nothing to do with uml): SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ -e s/sa110/arm/ \ -e s/s390x/s390/ -e s/parisc64/parisc/ \ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ ) config 64BIT bool "64-bit kernel" if ARCH = "x86" default ARCH != "i386" ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 If you want to stand on your head and demand that all these conventions be changed against all reason, I have nothing further to say. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 16:36, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >>> Sorry for chiming in, but... what about cross compiling? >>> SUBARCH=x86 should give you a 32-bit ia32 kernel, right? >> >> Correct. >> Users expect from SUBARCH=x86 a i386 32bit UML kernel. > > This is an insane expectation. This is kernel convention (it has > nothing to do with uml): Hmm, looks like I missed commit ffee0de411, thanks for pointing that out. Before ffee0de411 "make defconfig ARCH=x86" produced a 32bit defconfig. Now it produces a x86_64 defconfig. As UML is a variant of x86 it makes not much sense to do things the other way around even if we break assumptions. And, of course, this makes your patch valid. Can you also please ensure that your new defconfigs are minimal? See make savedefconfig. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Weinberger wrote: > And, of course, this makes your patch valid. > Can you also please ensure that your new defconfigs are minimal? Yeah, it's close to a minimal configuration for the 3.10 kernel (latest at the time of patch submission). I was aiming to minimize the diff between the current defconfig and the two new defconfigs in configs/. The slim diffstat does the talking: arch/um/Kconfig.common | 5 - arch/um/Makefile | 11 ++ arch/um/{defconfig => configs/i386_defconfig} | 209 +++++++++++++------- arch/um/{defconfig => configs/x86_64_defconfig} | 250 +++++++++++++++--------- arch/x86/um/Kconfig | 5 + 5 files changed, 306 insertions(+), 174 deletions(-) copy arch/um/{defconfig => configs/i386_defconfig} (86%) rename arch/um/{defconfig => configs/x86_64_defconfig} (83%) If we find some deficiencies, we can always update it. For now, please commit these two patches. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 26.09.2013 18:06, schrieb Ramkumar Ramachandra: > Richard Weinberger wrote: >> And, of course, this makes your patch valid. >> Can you also please ensure that your new defconfigs are minimal? > > Yeah, it's close to a minimal configuration for the 3.10 kernel > (latest at the time of patch submission). I was aiming to minimize the > diff between the current defconfig and the two new defconfigs in > configs/. The slim diffstat does the talking: > > arch/um/Kconfig.common | 5 - > arch/um/Makefile | 11 ++ > arch/um/{defconfig => configs/i386_defconfig} | 209 +++++++++++++------- > arch/um/{defconfig => configs/x86_64_defconfig} | 250 +++++++++++++++--------- > arch/x86/um/Kconfig | 5 + > 5 files changed, 306 insertions(+), 174 deletions(-) > copy arch/um/{defconfig => configs/i386_defconfig} (86%) > rename arch/um/{defconfig => configs/x86_64_defconfig} (83%) > > If we find some deficiencies, we can always update it. For now, please > commit these two patches. Please resend them with savedefconfig applied. There is no need to have three commits for that. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common index bceee66..a7ef0b4 100644 --- a/arch/um/Kconfig.common +++ b/arch/um/Kconfig.common @@ -58,7 +58,3 @@ config GENERIC_BUG config HZ int default 100 - -config SUBARCH - string - option env="SUBARCH" 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 HOST_DIR := arch/$(HEADER_ARCH) @@ -155,4 +156,4 @@ endef include/generated/user_constants.h: $(HOST_DIR)/um/user-offsets.s $(call filechk,gen-asm-offsets) -export SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS DEV_NULL_PATH +export USER_CFLAGS CFLAGS_NO_HARDENING OS DEV_NULL_PATH diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um index 36b62bc..91d088c 100644 --- a/arch/x86/Makefile.um +++ b/arch/x86/Makefile.um @@ -40,7 +40,7 @@ else START := 0x60000000 -KBUILD_CFLAGS += -fno-builtin -m64 +KBUILD_CFLAGS += -fno-builtin -m64 -mcmodel=large CHECKFLAGS += -m64 -D__x86_64__ KBUILD_AFLAGS += -m64 diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig index 14ef8d1..bb6df67 100644 --- a/arch/x86/um/Kconfig +++ b/arch/x86/um/Kconfig @@ -1,4 +1,4 @@ -mainmenu "User Mode Linux/$SUBARCH $KERNELVERSION Kernel Configuration" +mainmenu "User Mode Linux $KERNELVERSION Kernel Configuration" source "arch/um/Kconfig.common" @@ -15,8 +15,8 @@ config UML_X86 select GENERIC_FIND_FIRST_BIT config 64BIT - bool "64-bit kernel" if SUBARCH = "x86" - default SUBARCH != "i386" + bool "64-bit kernel" + default n config X86_32 def_bool !64BIT
From now on UML does no longer depend on SUBARCH and will never silently change CONFIG_64BIT. "make defconfig ARCH=um" produces now a .config with is suitable for your host arch. "make i386_defconfig ARCH=um" replaces "make defconfig ARCH=um SUBARCH=i386" "and make x86_64_defconfig ARCH=um" replaces "make defconfig ARCH=um SUBARCH=x86_64" Finally a "make ARCH=um" will produce an UML as described in your .config and you don't have to worry about setting the correct SUBARCH. This patch is based on: https://lkml.org/lkml/2013/7/4/396 Cc: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> --- arch/um/Kconfig.common | 4 ---- arch/um/Makefile | 21 +++++++++++---------- arch/x86/Makefile.um | 2 +- arch/x86/um/Kconfig | 6 +++--- 4 files changed, 15 insertions(+), 18 deletions(-)