* tip-bot for David Woodhouse <[email protected]> wrote:
> Commit-ID: 5a8a2d13b1526e306ff2a9fe12dc9d5878d355f9
> Gitweb: http://git.kernel.org/tip/5a8a2d13b1526e306ff2a9fe12dc9d5878d355f9
> Author: David Woodhouse <[email protected]>
> AuthorDate: Tue, 30 Jun 2009 12:10:21 +0100
> Committer: H. Peter Anvin <[email protected]>
> CommitDate: Thu, 3 Sep 2009 10:57:20 -0700
>
> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
-tip testing found that this commit broke the UML build:
/home/mingo/tip/arch/um/Makefile:52:
/home/mingo/tip/arch/um/Makefile-x86: No such file or directory
make[1]: *** No rule to make target `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
make: *** [sub-make] Error 2
Ingo
On Fri, 4 Sep 2009, Ingo Molnar wrote:
>> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
>
> -tip testing found that this commit broke the UML build:
>
> /home/mingo/tip/arch/um/Makefile:52:
> /home/mingo/tip/arch/um/Makefile-x86: No such file or directory
> make[1]: *** No rule to make target `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
> make: *** [sub-make] Error 2
Hm, doesn't that mean that UML has always been broken for ARCH=x86?
--
dwmw2
On 09/04/2009 08:33 AM, David Woodhouse wrote:
> On Fri, 4 Sep 2009, Ingo Molnar wrote:
>
>
>>> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
>>
>> -tip testing found that this commit broke the UML build:
>>
>> /home/mingo/tip/arch/um/Makefile:52:
>> /home/mingo/tip/arch/um/Makefile-x86: No such file or directory
>> make[1]: *** No rule to make target
>> `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
>> make: *** [sub-make] Error 2
>
> Hm, doesn't that mean that UML has always been broken for ARCH=x86?
>
Quite possible. ARCH=x86 hasn't exactly been widely used.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri, 04 Sep 2009 09:27:18 -0700 H. Peter Anvin wrote:
> On 09/04/2009 08:33 AM, David Woodhouse wrote:
> > On Fri, 4 Sep 2009, Ingo Molnar wrote:
> >
> >
> >>> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
> >>
> >> -tip testing found that this commit broke the UML build:
> >>
> >> /home/mingo/tip/arch/um/Makefile:52:
> >> /home/mingo/tip/arch/um/Makefile-x86: No such file or directory
> >> make[1]: *** No rule to make target
> >> `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
> >> make: *** [sub-make] Error 2
> >
> > Hm, doesn't that mean that UML has always been broken for ARCH=x86?
> >
>
> Quite possible. ARCH=x86 hasn't exactly been widely used.
what does ARCH=x86 mean?
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
On 09/04/2009 09:38 AM, Randy Dunlap wrote:
>>>
>> Quite possible. ARCH=x86 hasn't exactly been widely used.
>
> what does ARCH=x86 mean?
>
Treat 32 vs 64 bit as a normal Kconfig variable. Similar as for other
32/64-bit architectures.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
* H. Peter Anvin <[email protected]> wrote:
> On 09/04/2009 08:33 AM, David Woodhouse wrote:
> > On Fri, 4 Sep 2009, Ingo Molnar wrote:
> >
> >
> >>> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
> >>
> >> -tip testing found that this commit broke the UML build:
> >>
> >> /home/mingo/tip/arch/um/Makefile:52:
> >> /home/mingo/tip/arch/um/Makefile-x86: No such file or directory
> >> make[1]: *** No rule to make target
> >> `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
> >> make: *** [sub-make] Error 2
> >
> > Hm, doesn't that mean that UML has always been broken for ARCH=x86?
>
> Quite possible. ARCH=x86 hasn't exactly been widely used.
Note, i used 'make ARCH=um' so this commit cannot be pushed upwards
until this problem is fixed. It could very well be some missing
changes on the UML side.
Ingo
On 09/04/2009 11:31 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin <[email protected]> wrote:
>
>> On 09/04/2009 08:33 AM, David Woodhouse wrote:
>>> On Fri, 4 Sep 2009, Ingo Molnar wrote:
>>>
>>>
>>>>> x86: Don't silently override CONFIG_64BIT in 'make oldconfig'
>>>>
>>>> -tip testing found that this commit broke the UML build:
>>>>
>>>> /home/mingo/tip/arch/um/Makefile:52:
>>>> /home/mingo/tip/arch/um/Makefile-x86: No such file or directory
>>>> make[1]: *** No rule to make target
>>>> `/home/mingo/tip/arch/um/Makefile-x86'. Stop.
>>>> make: *** [sub-make] Error 2
>>>
>>> Hm, doesn't that mean that UML has always been broken for ARCH=x86?
>>
>> Quite possible. ARCH=x86 hasn't exactly been widely used.
>
> Note, i used 'make ARCH=um' so this commit cannot be pushed upwards
> until this problem is fixed. It could very well be some missing
> changes on the UML side.
>
Okay, the problem is the following: UM treats i386 and x86-64 as
separate architectures, and it gets very unhappy with SUBARCH=x86. A
trivial attempt to fix it:
diff --git a/arch/um/Makefile b/arch/um/Makefile
index 0728def..b1cc9cf 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -12,6 +12,17 @@ OS := $(shell uname -s)
# features.
SHELL := /bin/bash
+#
+# i386 and x86_64 are separate architectures to the UM build.
+#
+ifeq ($(SUBARCH),x86)
+ifeq ($(CONFIG_64BIT),y)
+SUBARCH := x86_64
+else
+SUBARCH := i386
+endif
+endif
+
filechk_gen_header = $<
core-y += $(ARCH_DIR)/kernel/ \
... didn't fix it, as "make defconfig" promptly made a 32-bit
configuration on my 64-bit system, and the build failed.
The "obvious" change of allowing SUBARCH to take values like i386 and
x86_64 is also wrong (and possibly have a DEFAULT_ARCH which can be
different than SUBARCH), because we have several instances of:
ifneq ($(SUBARCH),$(ARCH))
... in the build tree, and even have ugliness like:
[scripts/tags.h]
# Support um (which uses SUBARCH)
if [ "${ARCH}" = "um" ]; then
if [ "$SUBARCH" = "i386" ]; then
archinclude=x86
elif [ "$SUBARCH" = "x86_64" ]; then
archinclude=x86
else
archinclude=${SUBARCH}
fi
fi
Anyway... it sounds like we need to drop this commit for now and
re-merge it when there is a fix for UM.
Jeff, Sam, I would appreciate your suggestions as how best to fix this
kind of stuff...
-hpa
On 09/04/2009 11:57 AM, H. Peter Anvin wrote:
>
> Anyway... it sounds like we need to drop this commit for now and
> re-merge it when there is a fix for UM.
>
> Jeff, Sam, I would appreciate your suggestions as how best to fix this
> kind of stuff...
>
On that note, this issue isn't just limited to UM. klibc has to deal
with this issue too: a single kernel architecture may correspond to more
than one user-space architecture, and as far as userspace is concerned,
they are completely different.
-hpa
On Fri, 2009-09-04 at 09:38 -0700, Randy Dunlap wrote:
>
> what does ARCH=x86 mean?
A bit like ARCH=powerpc. It's the new combined architecture where 64-bit
vs. 32-bit is just a config choice. ARCH=i386 and ARCH=x86_64 are just
historical baggage, and should be dropped like ARCH=ppc and ARCH=ppc64
were.
--
dwmw2
On 09/04/2009 02:40 PM, David Woodhouse wrote:
> On Fri, 2009-09-04 at 09:38 -0700, Randy Dunlap wrote:
>>
>> what does ARCH=x86 mean?
>
> A bit like ARCH=powerpc. It's the new combined architecture where 64-bit
> vs. 32-bit is just a config choice. ARCH=i386 and ARCH=x86_64 are just
> historical baggage, and should be dropped like ARCH=ppc and ARCH=ppc64
> were.
>
>From a cursory look it looks like ARCH=powerpc won't work for UM, either.
-hpa
On Fri, Sep 04, 2009 at 11:57:58AM -0700, H. Peter Anvin wrote:
> The "obvious" change of allowing SUBARCH to take values like i386 and
> x86_64 is also wrong (and possibly have a DEFAULT_ARCH which can be
> different than SUBARCH), because we have several instances of:
>
> ifneq ($(SUBARCH),$(ARCH))
>
> ... in the build tree, and even have ugliness like:
>
> [scripts/tags.h]
> # Support um (which uses SUBARCH)
> if [ "${ARCH}" = "um" ]; then
> if [ "$SUBARCH" = "i386" ]; then
> archinclude=x86
> elif [ "$SUBARCH" = "x86_64" ]; then
> archinclude=x86
> else
> archinclude=${SUBARCH}
> fi
> fi
>
> Anyway... it sounds like we need to drop this commit for now and
> re-merge it when there is a fix for UM.
>
> Jeff, Sam, I would appreciate your suggestions as how best to fix this
> kind of stuff...
I figured out how to make this work - see below.
Jeff
--
Work email - jdike at linux dot intel dot com
commit 370d4e326094c053b7f602178a4303f958471136
Author: Jeff Dike <[email protected]>
Date: Fri Sep 11 17:07:36 2009 -0400
Make UML build with SUBARCH=x86
This patch makes UML build with David Woodhouse's commit
5a8a2d13b1526e306ff2a9fe12dc9d5878d355f9 in x86/linux-2.6-tip.
I start with Peter Anvin's patch to arch/um/Makefile:
+#
+# i386 and x86_64 are separate architectures to the UM build.
+#
+ifeq ($(SUBARCH),x86)
+ifeq ($(CONFIG_64BIT),y)
+SUBARCH := x86_64
+else
+SUBARCH := i386
+endif
+endif
and fix a couple of things. CONFIG_64BIT was defined in terms of
SUBARCH, so this patch is a bit circular in making SUBARCH depend on
CONFIG_64BIT. I do like x86 and change the test to
ifeq ($(shell uname -m),x86_64)
SUBARCH is used in other places, so in order to just confine changes
to UML, I define UML_SUBARCH to be either x86_64 or i386 and
heavy-handedly do s/SUBARCH/UML_SUBARCH in arch/um/Makefile and
arch/um/os-Linux/Makefile. This makes the UML build descend through
the existing -i386 and -x86_64 directories.
CONFIG_64BIT needs to be defined correctly. This used to be done by
seeing if SUBARCH = "x86_64". I replace SUBARCH with UML_SUBARCH,
which is exported from the Makefile.
This induces a build loop by causing include/config/auto.conf.cmd to
see an unexpected mismatch between UML_SUBARCH and x86_64
because the arch Makefile hasn't been included yet, so UML_SUBARCH
hasn't been set yet. Somehow, this causes infinite Makefile updates
and make restarts. I fixed this by moving the include of the arch
Makefile above the auto.conf stuff. UML is fine with this, but maybe
other arches won't be.
diff --git a/Makefile b/Makefile
index 60de4ef..c25406f 100644
--- a/Makefile
+++ b/Makefile
@@ -473,6 +473,8 @@ libs-y := lib/
core-y := usr/
endif # KBUILD_EXTMOD
+include $(srctree)/arch/$(SRCARCH)/Makefile
+
ifeq ($(dot-config),1)
# Read in config
-include include/config/auto.conf
@@ -524,7 +526,6 @@ else
KBUILD_CFLAGS += -O2
endif
-include $(srctree)/arch/$(SRCARCH)/Makefile
ifneq ($(CONFIG_FRAME_WARN),0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 0d207e7..686c7b0 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -75,3 +75,7 @@ config HZ
config SUBARCH
string
option env="SUBARCH"
+
+config UML_SUBARCH
+ string
+ option env="UML_SUBARCH"
diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86
index 5ee3280..e915680 100644
--- a/arch/um/Kconfig.x86
+++ b/arch/um/Kconfig.x86
@@ -13,7 +13,7 @@ config UML_X86
config 64BIT
bool
- default SUBARCH = "x86_64"
+ default UML_SUBARCH = "x86_64"
config X86_32
def_bool !64BIT
diff --git a/arch/um/Makefile b/arch/um/Makefile
index 0728def..28419ef 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -12,6 +12,18 @@ OS := $(shell uname -s)
# features.
SHELL := /bin/bash
+UML_SUBARCH = $(SUBARCH)
+#
+# i386 and x86_64 are separate architectures to the UM build.
+#
+ifeq ($(SUBARCH),x86)
+ifeq ($(shell uname -m),x86_64)
+ UML_SUBARCH := x86_64
+else
+ UML_SUBARCH := i386
+endif
+endif
+
filechk_gen_header = $<
core-y += $(ARCH_DIR)/kernel/ \
@@ -24,11 +36,11 @@ include $(srctree)/$(ARCH_DIR)/Makefile-skas
SHARED_HEADERS := $(ARCH_DIR)/include/shared
ARCH_INCLUDE := -I$(srctree)/$(SHARED_HEADERS)
-ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH)/shared
+ARCH_INCLUDE += -I$(srctree)/$(ARCH_DIR)/sys-$(UML_SUBARCH)/shared
ifneq ($(KBUILD_SRC),)
ARCH_INCLUDE += -I$(SHARED_HEADERS)
endif
-KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH)
+KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(UML_SUBARCH)
# -Dvmap=kernel_vmap prevents anything from referencing the libpcap.o symbol so
# named - it's a common symbol in libpcap, so we get a binary which crashes.
@@ -38,7 +50,7 @@ KBUILD_CPPFLAGS += -I$(srctree)/$(ARCH_DIR)/sys-$(SUBARCH)
#
# These apply to USER_CFLAGS to.
-KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(SUBARCH)\" \
+KBUILD_CFLAGS += $(CFLAGS) $(CFLAGS-y) -D__arch_um__ -DSUBARCH=\"$(UML_SUBARCH)\" \
$(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap \
-Din6addr_loopback=kernel_in6addr_loopback \
-Din6addr_any=kernel_in6addr_any
@@ -49,7 +61,7 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\
$(patsubst -I%,,$(KBUILD_CFLAGS)))) $(ARCH_INCLUDE) $(MODE_INCLUDE) \
$(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64
-include $(srctree)/$(ARCH_DIR)/Makefile-$(SUBARCH)
+include $(srctree)/$(ARCH_DIR)/Makefile-$(UML_SUBARCH)
#This will adjust *FLAGS accordingly to the platform.
include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
@@ -99,7 +111,7 @@ CFLAGS_NO_HARDENING := $(call cc-option, -fno-PIC,) $(call cc-option, -fno-pic,)
CONFIG_KERNEL_STACK_ORDER ?= 2
STACK_SIZE := $(shell echo $$[ 4096 * (1 << $(CONFIG_KERNEL_STACK_ORDER)) ] )
-CPPFLAGS_vmlinux.lds = -U$(SUBARCH) -DSTART=$(START) -DELF_ARCH=$(ELF_ARCH) \
+CPPFLAGS_vmlinux.lds = -U$(UML_SUBARCH) -DSTART=$(START) -DELF_ARCH=$(ELF_ARCH) \
-DELF_FORMAT="$(ELF_FORMAT)" -DKERNEL_STACK_SIZE=$(STACK_SIZE)
# The wrappers will select whether using "malloc" or the kernel allocator.
@@ -129,8 +141,8 @@ archclean:
# Generated files
-$(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s: FORCE
- $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(SUBARCH) $@
+$(ARCH_DIR)/sys-$(UML_SUBARCH)/user-offsets.s: FORCE
+ $(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(UML_SUBARCH) $@
define filechk_gen-asm-offsets
(set -e; \
@@ -145,7 +157,7 @@ define filechk_gen-asm-offsets
echo ""; )
endef
-$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s
+$(SHARED_HEADERS)/user_constants.h: $(ARCH_DIR)/sys-$(UML_SUBARCH)/user-offsets.s
$(call filechk,gen-asm-offsets)
$(SHARED_HEADERS)/kern_constants.h:
@@ -153,3 +165,4 @@ $(SHARED_HEADERS)/kern_constants.h:
$(Q)echo '#include "../../../../include/asm/asm-offsets.h"' >$@
export SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH
+export UML_SUBARCH
diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile
index d66f038..2b23018 100644
--- a/arch/um/os-Linux/Makefile
+++ b/arch/um/os-Linux/Makefile
@@ -5,13 +5,13 @@
obj-y = aio.o elf_aux.o execvp.o file.o helper.o irq.o main.o mem.o process.o \
registers.o sigio.o signal.o start_up.o time.o tty.o uaccess.o \
- umid.o tls.o user_syms.o util.o drivers/ sys-$(SUBARCH)/ skas/
+ umid.o tls.o user_syms.o util.o drivers/ sys-$(UML_SUBARCH)/ skas/
USER_OBJS := $(user-objs-y) aio.o elf_aux.o execvp.o file.o helper.o irq.o \
main.o mem.o process.o registers.o sigio.o signal.o start_up.o time.o \
tty.o tls.o uaccess.o umid.o util.o
-CFLAGS_user_syms.o += -DSUBARCH_$(SUBARCH)
+CFLAGS_user_syms.o += -DSUBARCH_$(UML_SUBARCH)
HAVE_AIO_ABI := $(shell [ -r /usr/include/linux/aio_abi.h ] && \
echo -DHAVE_AIO_ABI )
On 09/11/2009 02:16 PM, Jeff Dike wrote:
>
> I figured out how to make this work - see below.
>
> Jeff
>
Jeff, could you re-send this as a proper patch with an SOB line?
-hpa
On Mon, Sep 14, 2009 at 04:29:38PM -0700, H. Peter Anvin wrote:
> Jeff, could you re-send this as a proper patch with an SOB line?
I could - I wanted to get it out for comment first in case anyone had
any conniptions, especially about moving the include of the arch
Makefile.
I'll take another look at it tomorrow and send it out properly...
Jeff
Jeff Dike wrote:
> On Mon, Sep 14, 2009 at 04:29:38PM -0700, H. Peter Anvin wrote:
>> Jeff, could you re-send this as a proper patch with an SOB line?
>
> I could - I wanted to get it out for comment first in case anyone had
> any conniptions, especially about moving the include of the arch
> Makefile.
>
> I'll take another look at it tomorrow and send it out properly...
>
> Jeff
Ping on this? Also, Sam, it would be great if you could comment on the
patch:
http://[email protected]
-hpa
On Fri, Sep 25, 2009 at 02:03:47AM -0700, H. Peter Anvin wrote:
> Jeff Dike wrote:
>> On Mon, Sep 14, 2009 at 04:29:38PM -0700, H. Peter Anvin wrote:
>>> Jeff, could you re-send this as a proper patch with an SOB line?
>>
>> I could - I wanted to get it out for comment first in case anyone had
>> any conniptions, especially about moving the include of the arch
>> Makefile.
>>
>> I'll take another look at it tomorrow and send it out properly...
>>
>> Jeff
>
> Ping on this? Also, Sam, it would be great if you could comment on the
> patch:
>
> http://[email protected]
I took a quick look at it this weekend. My first reaction was that um
is now again doing it best to workaround something rather than to
use something.
But I have not had time to come up with any alternative proposal.
I may give it a spin the coming weekend.
Sam