Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Ingo Molnar]

* tip-bot for David Woodhouse <dwmw2@infradead.org> wrote:

> Commit-ID:  5a8a2d13b1526e306ff2a9fe12dc9d5878d355f9
> Gitweb:     http://git.kernel.org/tip/5a8a2d13b1526e306ff2a9fe12dc9d5878d355f9
> Author:     David Woodhouse <dwmw2@infradead.org>
> AuthorDate: Tue, 30 Jun 2009 12:10:21 +0100
> Committer:  H. Peter Anvin <hpa@zytor.com>
> 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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[David Woodhouse]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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.

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Randy Dunlap]

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/

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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.

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> 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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

On 09/04/2009 11:31 AM, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@zytor.com> 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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[David Woodhouse]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Jeff Dike]

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 <jdike@kvm.user-mode-linux.org>
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 )

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Jeff Dike]

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

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[H. Peter Anvin]

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://marc.info?i=20090911211654.GA11399@c2.user-mode-linux.org

	-hpa

Re: [tip:x86/kbuild] x86: Don't silently override CONFIG_64BIT in 'make oldconfig'

[Sam Ravnborg]

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://marc.info?i=20090911211654.GA11399@c2.user-mode-linux.org

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