[PATCH 2/5] um: Remove gratuitous use of $(SUBARCH) in Makefile-i386

[PATCH 2/5] um: Remove gratuitous use of $(SUBARCH) in Makefile-i386

[David Woodhouse]

If we're in Makefile-i386, we know what the target architecture is.
Don't try to be cute.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
 arch/um/Makefile-i386 |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386
index 302cbe5..75b3309 100644
--- a/arch/um/Makefile-i386
+++ b/arch/um/Makefile-i386
@@ -5,8 +5,8 @@ TOP_ADDR := $(CONFIG_TOP_ADDR)
 START := 0x8048000
 
 LDFLAGS			+= -m elf_i386
-ELF_ARCH		:= $(SUBARCH)
-ELF_FORMAT 		:= elf32-$(SUBARCH)
+ELF_ARCH		:= i386
+ELF_FORMAT 		:= elf32-i386
 OBJCOPYFLAGS  		:= -O binary -R .note -R .comment -S
 HEADER_ARCH		:= x86
 CHECKFLAGS	+= -D__i386__
-- 
1.7.6

[PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[David Woodhouse]

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
 arch/um/os-Linux/Makefile    |    2 --
 arch/um/os-Linux/user_syms.c |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile
index b33f4df..78658a7 100644
--- a/arch/um/os-Linux/Makefile
+++ b/arch/um/os-Linux/Makefile
@@ -13,8 +13,6 @@ 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)
-
 HAVE_AIO_ABI := $(shell [ -r /usr/include/linux/aio_abi.h ] && \
 	echo -DHAVE_AIO_ABI )
 CFLAGS_aio.o += $(HAVE_AIO_ABI)
diff --git a/arch/um/os-Linux/user_syms.c b/arch/um/os-Linux/user_syms.c
index 45ffe46..9165513 100644
--- a/arch/um/os-Linux/user_syms.c
+++ b/arch/um/os-Linux/user_syms.c
@@ -45,7 +45,7 @@ EXPORT_SYMBOL(readdir64);
 extern void truncate64(void) __attribute__((weak));
 EXPORT_SYMBOL(truncate64);
 
-#ifdef SUBARCH_i386
+#ifdef __i386__
 EXPORT_SYMBOL(vsyscall_ehdr);
 EXPORT_SYMBOL(vsyscall_end);
 #endif
-- 
1.7.6

[PATCH 3/5] um: Always use -m32 when building for i386.

[David Woodhouse]

If the compiler doesn't understand it, cc-option will deal with that.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
 arch/um/Makefile-i386 |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386
index 75b3309..d65e316 100644
--- a/arch/um/Makefile-i386
+++ b/arch/um/Makefile-i386
@@ -11,16 +11,12 @@ OBJCOPYFLAGS  		:= -O binary -R .note -R .comment -S
 HEADER_ARCH		:= x86
 CHECKFLAGS	+= -D__i386__
 
-ifeq ("$(origin SUBARCH)", "command line")
-ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)")
 KBUILD_CFLAGS		+= $(call cc-option,-m32)
 KBUILD_AFLAGS		+= $(call cc-option,-m32)
 LINK-y			+= $(call cc-option,-m32)
 UML_OBJCOPYFLAGS	+= -F $(ELF_FORMAT)
 
 export LDFLAGS HOSTCFLAGS HOSTLDFLAGS UML_OBJCOPYFLAGS
-endif
-endif
 
 # First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
 include $(srctree)/arch/x86/Makefile_32.cpu
-- 
1.7.6

[PATCH 4/5] um: Do not define SUBARCH in CFLAGS

[David Woodhouse]

There are no users of this, and not a lot of reasons why people would *need*
to use it when the compiler defines standard macros for the architecture
anyway.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---

Did I miss somewhere that this is actually used?

 arch/um/Makefile        |    2 +-
 arch/um/kernel/Makefile |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/Makefile b/arch/um/Makefile
index fab8121..2a54640 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -38,7 +38,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__ \
 	$(ARCH_INCLUDE) $(MODE_INCLUDE) -Dvmap=kernel_vmap	\
 	-Din6addr_loopback=kernel_in6addr_loopback \
 	-Din6addr_any=kernel_in6addr_any
diff --git a/arch/um/kernel/Makefile b/arch/um/kernel/Makefile
index c4491c1..48a4f9f 100644
--- a/arch/um/kernel/Makefile
+++ b/arch/um/kernel/Makefile
@@ -3,7 +3,7 @@
 # Licensed under the GPL
 #
 
-CPPFLAGS_vmlinux.lds := -U$(SUBARCH) -DSTART=$(LDS_START) \
+CPPFLAGS_vmlinux.lds := -DSTART=$(LDS_START) \
                         -DELF_ARCH=$(LDS_ELF_ARCH)        \
                         -DELF_FORMAT=$(LDS_ELF_FORMAT)
 extra-y := vmlinux.lds
-- 
1.7.6

[PATCH 5/5] um: Fix SUBARCH=x86 build

[David Woodhouse]

This fixes the build for 'ARCH=um SUBARCH=x86', by introducing a new
USERARCH variable which is set to either i386 or x86_64 according to the
configuration option CONFIG_64BIT.

If we want to support x32 later, that could quite happily be a config
option too. We have a stated goal of moving even the top-level ARCH=
setting to a configuration option, and moving away from the hard-coded
variable overrides on the command line.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
 arch/um/Kconfig.x86            |    4 ++--
 arch/um/Makefile               |   25 ++++++++++++++++++-------
 arch/um/os-Linux/Makefile      |    2 +-
 arch/um/scripts/Makefile.rules |    4 ++--
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86
index d31ecf3..576b732 100644
--- a/arch/um/Kconfig.x86
+++ b/arch/um/Kconfig.x86
@@ -19,8 +19,8 @@ config UML_X86
 	select GENERIC_FIND_FIRST_BIT
 
 config 64BIT
-	bool
-	default SUBARCH = "x86_64"
+	bool "64-bit kernel" if SUBARCH = "x86"
+	default SUBARCH != "i386"
 
 config X86_32
 	def_bool !64BIT
diff --git a/arch/um/Makefile b/arch/um/Makefile
index 2a54640..44f89c9 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -12,6 +12,17 @@ OS := $(shell uname -s)
 # features.
 SHELL := /bin/bash
 
+# The i386/x86_64 merge hasn't really happened in um-land yet. Fake it.
+ifeq ($(SUBARCH),x86)
+ifeq ($(CONFIG_64BIT),y)
+USERARCH := x86_64
+else
+USERARCH := i386
+endif
+else
+USERARCH := $(SUBARCH)
+endif
+
 filechk_gen_header = $<
 
 core-y			+= $(ARCH_DIR)/kernel/		\
@@ -24,11 +35,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-$(USERARCH)/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-$(USERARCH)
 
 # -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.
@@ -49,7 +60,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-$(USERARCH)
 
 #This will adjust *FLAGS accordingly to the platform.
 include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
@@ -128,8 +139,8 @@ archclean:
 
 # Generated files
 
-$(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.s: FORCE
-	$(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(SUBARCH) $@
+$(ARCH_DIR)/sys-$(USERARCH)/user-offsets.s: FORCE
+	$(Q)$(MAKE) $(build)=$(ARCH_DIR)/sys-$(USERARCH) $@
 
 define filechk_gen-asm-offsets
         (set -e; \
@@ -144,11 +155,11 @@ 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-$(USERARCH)/user-offsets.s
 	$(call filechk,gen-asm-offsets)
 
 $(SHARED_HEADERS)/kern_constants.h:
 	$(Q)mkdir -p $(dir $@)
 	$(Q)echo '#include "../../../../include/generated/asm-offsets.h"' >$@
 
-export SUBARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH
+export SUBARCH USERARCH USER_CFLAGS CFLAGS_NO_HARDENING OS HEADER_ARCH DEV_NULL_PATH
diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile
index 78658a7..a10a078 100644
--- a/arch/um/os-Linux/Makefile
+++ b/arch/um/os-Linux/Makefile
@@ -5,7 +5,7 @@
 
 obj-y = aio.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-$(USERARCH)/ skas/
 
 obj-$(CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA) += elf_aux.o
 
diff --git a/arch/um/scripts/Makefile.rules b/arch/um/scripts/Makefile.rules
index 61107b6..9af0cd5 100644
--- a/arch/um/scripts/Makefile.rules
+++ b/arch/um/scripts/Makefile.rules
@@ -10,7 +10,7 @@ USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
 $(USER_OBJS:.o=.%): \
 	c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) $(CFLAGS_$(basetarget).o)
 $(USER_OBJS) : CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ \
-	-Dunix -D__unix__ -D__$(SUBARCH)__ $(CF)
+	-Dunix -D__unix__ -D__$(USERARCH)__ $(CF)
 
 # These are like USER_OBJS but filter USER_CFLAGS through unprofile instead of
 # using it directly.
@@ -19,7 +19,7 @@ UNPROFILE_OBJS := $(foreach file,$(UNPROFILE_OBJS),$(obj)/$(file))
 $(UNPROFILE_OBJS:.o=.%): \
 	c_flags = -Wp,-MD,$(depfile) $(call unprofile,$(USER_CFLAGS)) $(CFLAGS_$(basetarget).o)
 $(UNPROFILE_OBJS) : CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ \
-	-Dunix -D__unix__ -D__$(SUBARCH)__ $(CF)
+	-Dunix -D__unix__ -D__$(USERARCH)__ $(CF)
 
 # The stubs can't try to call mcount or update basic block data
 define unprofile
-- 
1.7.6

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[richard -rw- weinberger]

On Sun, Jul 31, 2011 at 1:02 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> ---
>  arch/um/os-Linux/Makefile    |    2 --
>  arch/um/os-Linux/user_syms.c |    2 +-
>  2 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile
> index b33f4df..78658a7 100644
> --- a/arch/um/os-Linux/Makefile
> +++ b/arch/um/os-Linux/Makefile
> @@ -13,8 +13,6 @@ 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)
> -
>  HAVE_AIO_ABI := $(shell [ -r /usr/include/linux/aio_abi.h ] && \
>        echo -DHAVE_AIO_ABI )
>  CFLAGS_aio.o += $(HAVE_AIO_ABI)
> diff --git a/arch/um/os-Linux/user_syms.c b/arch/um/os-Linux/user_syms.c
> index 45ffe46..9165513 100644
> --- a/arch/um/os-Linux/user_syms.c
> +++ b/arch/um/os-Linux/user_syms.c
> @@ -45,7 +45,7 @@ EXPORT_SYMBOL(readdir64);
>  extern void truncate64(void) __attribute__((weak));
>  EXPORT_SYMBOL(truncate64);
>
> -#ifdef SUBARCH_i386
> +#ifdef __i386__
>  EXPORT_SYMBOL(vsyscall_ehdr);
>  EXPORT_SYMBOL(vsyscall_end);
>  #endif

Why do we need this?

-- 
Thanks,
//richard

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[David Woodhouse]

On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote:
> 
> Why do we need this? 

The arch/x86_64 and arch/i386 directories were removed from the kernel
four years ago, and replaced by the 'x86' arch. UML is still dependent
on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch
sequence I just posted makes it cope with SUBARCH=x86.

-- 
dwmw2

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Sun, Jul 31, 2011 at 11:24:21PM +0100, David Woodhouse wrote:
> On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote:
> > 
> > Why do we need this? 
> 
> The arch/x86_64 and arch/i386 directories were removed from the kernel
> four years ago, and replaced by the 'x86' arch. UML is still dependent
> on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch
> sequence I just posted makes it cope with SUBARCH=x86.

Hell, no.  If you want to do it, do it the right way.  See #x86_merge in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Sun, Jul 31, 2011 at 11:48:35PM +0100, Al Viro wrote:
> On Sun, Jul 31, 2011 at 11:24:21PM +0100, David Woodhouse wrote:
> > On Mon, 2011-08-01 at 00:11 +0200, richard -rw- weinberger wrote:
> > > 
> > > Why do we need this? 
> > 
> > The arch/x86_64 and arch/i386 directories were removed from the kernel
> > four years ago, and replaced by the 'x86' arch. UML is still dependent
> > on the legacy SUBARCH=i386 and SUBARCH=x86_64 settings, and the patch
> > sequence I just posted makes it cope with SUBARCH=x86.
> 
> Hell, no.  If you want to do it, do it the right way.  See #x86_merge in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/

FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
arch/x86/um/Makefile.defs.  Next after that - arch/powerpc/um (and yes,
it means resurrected uml/ppc port; for now - only ppc32, since I have no
ppc64 boxen to test on).

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[David Woodhouse]

On Sun, 2011-07-31 at 23:48 +0100, Al Viro wrote:
> Hell, no.  If you want to do it, do it the right way.  See #x86_merge in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/

 255 files changed, 6848 insertions(+), 7816 deletions(-)

Absolutely, but slightly out of scope for what I was trying to do :)

I just posted a *minimal* set of changes to make the UML build system
cope; fixing the code as you've done is *definitely* the better option.
Is there a reason it didn't go upstream yet?

It just wants this, to make the CONFIG_64BIT option visible when
SUBARCH=x86 and also put it *first*.

diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86
index d31ecf3..630db12 100644
--- a/arch/um/Kconfig.x86
+++ b/arch/um/Kconfig.x86
@@ -1,5 +1,19 @@
 mainmenu "User Mode Linux/$SUBARCH $KERNELVERSION Kernel Configuration"
 
+config 64BIT
+	bool "Build 64-bit kernel" if SUBARCH = "x86"
+	default SUBARCH != "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
+
+config X86_32
+	def_bool !64BIT
+	select HAVE_AOUT
+
+config X86_64
+	def_bool 64BIT
+
 source "arch/um/Kconfig.common"
 
 menu "UML-specific options"
@@ -18,17 +32,6 @@ config UML_X86
 	def_bool y
 	select GENERIC_FIND_FIRST_BIT
 
-config 64BIT
-	bool
-	default SUBARCH = "x86_64"
-
-config X86_32
-	def_bool !64BIT
-	select HAVE_AOUT
-
-config X86_64
-	def_bool 64BIT
-
 config RWSEM_XCHGADD_ALGORITHM
 	def_bool X86_XADD && 64BIT
 

-- 
dwmw2

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[David Woodhouse]

On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
> arch/x86/um/Makefile.defs.  Next after that - arch/powerpc/um (and yes,
> it means resurrected uml/ppc port; for now - only ppc32, since I have no
> ppc64 boxen to test on). 

I can give you an account on a ppc64 box if that would help...

What you've done so far, with the one extra patch I just sent, seems
perfectly sufficient to make it cope with SUBARCH defaulting to x86
instead of to i386 or x86_64. Are you happy to push it before you do the
rest of the refactoring/moving?

-- 
dwmw2

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[richard -rw- weinberger]

On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
>> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
>> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
>> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
>> arch/x86/um/Makefile.defs.  Next after that - arch/powerpc/um (and yes,
>> it means resurrected uml/ppc port; for now - only ppc32, since I have no
>> ppc64 boxen to test on).
>
> I can give you an account on a ppc64 box if that would help...

Isn't UML on ppc broken since ages?
As I don't have a ppc box I could never test it...

-- 
Thanks,
//richard

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[David Woodhouse]

On Mon, 2011-08-01 at 01:17 +0200, richard -rw- weinberger wrote:
> Isn't UML on ppc broken since ages?

Since before the ppc{,64} -> powerpc merge, by the looks of it.

> As I don't have a ppc box I could never test it... 

Give SSH public key and preferred username...

-- 
dwmw2

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Mon, Aug 01, 2011 at 01:17:17AM +0200, richard -rw- weinberger wrote:
> On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
> >> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
> >> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
> >> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
> >> arch/x86/um/Makefile.defs. ?Next after that - arch/powerpc/um (and yes,
> >> it means resurrected uml/ppc port; for now - only ppc32, since I have no
> >> ppc64 boxen to test on).
> >
> > I can give you an account on a ppc64 box if that would help...
> 
> Isn't UML on ppc broken since ages?

Yes.  Resurrected is not the right word here, sorry...

Anyway, could you take a look at the git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/,
branch x86_merge and comment?  It doesn't include stuff from this
thread (yet); what it does is
	* further headers cleanups
	* sys-{i386,x86_64} merged; all[1] x86-specific code taken first
to arch/um/sys-x86 and then (by final commit) to arch/x86/um.  IMO that's
the right place for it - target-dependent code is better off not hidden
from maintainers of the target arch.  When we get other ports to working
shape, their target-specific parts ought to go into arch/<target>/um.
	* hopefully saner treatment of sigcontext; should make life easier
for other ports.
	
[1] theoretically - in reality we still have more than a few x86-isms in
"generic" um headers in arch/um/include/asm.

Re: [uml-devel] [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Geert Uytterhoeven]

On Mon, Aug 1, 2011 at 06:32, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Aug 01, 2011 at 01:17:17AM +0200, richard -rw- weinberger wrote:
>> On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
>> >> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
>> >> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
>> >> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
>> >> arch/x86/um/Makefile.defs. ?Next after that - arch/powerpc/um (and yes,
>> >> it means resurrected uml/ppc port; for now - only ppc32, since I have no
>> >> ppc64 boxen to test on).
>> >
>> > I can give you an account on a ppc64 box if that would help...
>>
>> Isn't UML on ppc broken since ages?
>
> Yes.  Resurrected is not the right word here, sorry...

Oh, what a disappointment. I really hoped it was true...

BTW, how much work would it be to port UML to ARM? Would be nice-to-have on
your Android phone, as it can provide a full Linux userspace without
requiring rooting
the phone.

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

Re: [uml-devel] [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[richard -rw- weinberger]

On Mon, Aug 1, 2011 at 12:04 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> BTW, how much work would it be to port UML to ARM? Would be nice-to-have on
> your Android phone, as it can provide a full Linux userspace without
> requiring rooting
> the phone.
>

Depends how strong your UML- and ARM-fu is. ;-)
I'm sure it will be non-trivial...

-- 
Thanks,
//richard

Re: [uml-devel] [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Mon, Aug 01, 2011 at 12:04:37PM +0200, Geert Uytterhoeven wrote:
> > Yes. ??Resurrected is not the right word here, sorry...
> 
> Oh, what a disappointment. I really hoped it was true...
> 
> BTW, how much work would it be to port UML to ARM? Would be nice-to-have on
> your Android phone, as it can provide a full Linux userspace without
> requiring rooting
> the phone.

Moderately unpleasant, but not fatally so.  I have no idea how often will
cache aliasing bite you, though.  We really need to get non-x86 ports
working to see how many portability issues are there; what I've got for
ppc is promising, but very preliminary...

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[richard -rw- weinberger]

On Mon, Aug 1, 2011 at 6:32 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> Anyway, could you take a look at the git tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/,
> branch x86_merge and comment?  It doesn't include stuff from this
> thread (yet); what it does is
>        * further headers cleanups
>        * sys-{i386,x86_64} merged; all[1] x86-specific code taken first
> to arch/um/sys-x86 and then (by final commit) to arch/x86/um.  IMO that's
> the right place for it - target-dependent code is better off not hidden
> from maintainers of the target arch.  When we get other ports to working
> shape, their target-specific parts ought to go into arch/<target>/um.
>        * hopefully saner treatment of sigcontext; should make life easier
> for other ports.
>
> [1] theoretically - in reality we still have more than a few x86-isms in
> "generic" um headers in arch/um/include/asm.
>

Ok, will look at it in the next few days.
"sys-{i386,x86_64} merged" sounds great!

-- 
Thanks,
//richard

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Mon, Aug 01, 2011 at 07:52:35PM +0200, richard -rw- weinberger wrote:

> Ok, will look at it in the next few days.
> "sys-{i386,x86_64} merged" sounds great!

	Update pushed; x86-specific stuff moved to arch/x86/um, more things
merged/cleaned up.  Works here, both for 32bit and 64bit builds...  At least
as well as the mainline one does, that is - there still are two very annoying
issues, shared with mainline at least as far back as 2.6.36:
	* dancing close to OOM sometimes ends up with reserved pages showing
up in pagetables.  Code in mm/* is Not Happy(tm)...
	* tty-on-xterm sometimes crashes on the first keysyms reaching it;
as far as I can tell, it's something related to SIGWINCH handling - whether
it happens or not depends on the way xterm windows are laid out and flipping
between them first seems to prevent that shit.  If it hasn't happened at once,
it won't happen at all...  Something in drivers/chan or drivers/line, most
likely...

	I can post the damn thing as patch series, but it's about 380Mb
even with git format-patch -M and 78-posting mailbomb is a bit over the top
anyway...

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Wed, Aug 10, 2011 at 12:38:17AM +0100, Al Viro wrote:

> 	* tty-on-xterm sometimes crashes on the first keysyms reaching it;
> as far as I can tell, it's something related to SIGWINCH handling - whether
> it happens or not depends on the way xterm windows are laid out and flipping
> between them first seems to prevent that shit.  If it hasn't happened at once,
> it won't happen at all...  Something in drivers/chan or drivers/line, most
> likely...

FWIW, what I'm seeing there is chan_interrupt() with tty that has definitely
been kfree'd.  What happens is that we have several opened files for
given tty and they all get closed in parallel.  Now, ->release() of
tty calls ->close() of driver (line_close() in this case) and then
gets around to decrementing tty->count.  As the result, *all* callers
of line_close() see line->tty->count > 1 and leave line->tty not reset to
NULL.  Oops...

Moral: do not use the counters on upper layer objects unless you know
what you are doing *and* know what will happen to that upper layer in
years to come...

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

> FWIW, what I'm seeing there is chan_interrupt() with tty that has definitely
> been kfree'd.  What happens is that we have several opened files for
> given tty and they all get closed in parallel.  Now, ->release() of
> tty calls ->close() of driver (line_close() in this case) and then
> gets around to decrementing tty->count.  As the result, *all* callers
> of line_close() see line->tty->count > 1 and leave line->tty not reset to
> NULL.  Oops...
> 
> Moral: do not use the counters on upper layer objects unless you know
> what you are doing *and* know what will happen to that upper layer in
> years to come...

Fixed and pushed (um-header.git #master); however, looking around that area
shows more races ;-/  Incidentally, why the hell is ->chan_list a cyclic list?
Holding at most two elements...  Why not an array of two possibly NULL
pointers?  And what is chan->primary?  Unless I'm seriously misreading that
code, it's always 1; moreover, all instances of the method that gets ->primary
value as argument ignore that argument completely...

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Wed, Aug 10, 2011 at 06:44:32PM +0100, Al Viro wrote:

> Fixed and pushed (um-header.git #master); however, looking around that area
> shows more races ;-/

Such as, for example, seriously broken handling of free_winch(): delaying
free_irq() until after return from IRQ handler is nice, but not enough -
freeing struct winch itself (or winch->stack, for that matter) is also best
left until after free_irq().  Normal way to do that is schedule_work()...
Fixed and pushed...

Folks, I don't know what to do with all that stuff; as far as I'm concerned
the ideal variant would be to have functioning git tree maintained by Richard.
Is that possible?  I can ask to start pulling um-header.git into linux-next,
but I would very much prefer to avoid that, TYVM...  If nothing else, ACK/NAK
on the stuff in there should be done by architecture maintainer(s).

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[richard -rw- weinberger]

On Thu, Aug 11, 2011 at 6:23 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Wed, Aug 10, 2011 at 06:44:32PM +0100, Al Viro wrote:
>
>> Fixed and pushed (um-header.git #master); however, looking around that area
>> shows more races ;-/
>
> Such as, for example, seriously broken handling of free_winch(): delaying
> free_irq() until after return from IRQ handler is nice, but not enough -
> freeing struct winch itself (or winch->stack, for that matter) is also best
> left until after free_irq().  Normal way to do that is schedule_work()...
> Fixed and pushed...
>
> Folks, I don't know what to do with all that stuff; as far as I'm concerned
> the ideal variant would be to have functioning git tree maintained by Richard.
> Is that possible?  I can ask to start pulling um-header.git into linux-next,
> but I would very much prefer to avoid that, TYVM...  If nothing else, ACK/NAK
> on the stuff in there should be done by architecture maintainer(s).
>

Sorry for the delay.
Writing my theses consumes a lot of my time...

I've already started reviewing and testing your changes.
Currently they life in my local git repo.
But a git.kernel.org repo is on the way!

Later I'll submit all changes to akpm.

-- 
Thanks,
//richard

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

[Al Viro]

On Thu, Aug 11, 2011 at 02:13:22PM +0200, richard -rw- weinberger wrote:

> Sorry for the delay.
> Writing my theses consumes a lot of my time...
> 
> I've already started reviewing and testing your changes.
> Currently they life in my local git repo.
> But a git.kernel.org repo is on the way!
> 
> Later I'll submit all changes to akpm.

OK...  It does end up in linux-next, so...  OTOH, why not send direct pull
requests to Linus?

Speaking of more fun in there:
	* coredumps do not contain fp registers; fixable by switching to
what x86 is doing (CORE_DUMP_USE_REGSET and corresponding bits in uml-x86
ptrace.c - arch/x86/um/ptrace*.c in this tree, arch/um/sys-*/ptrace.c in
mainline)
	* more drivers/{lin,chan*}.c races ;-/  Protecting setup_one_line()
from being done on opened ones is nice, but we are really not safe until
parse_chan_pair() has been finished...  I've partial fixes, but it's not
quite trivial.
	* fixrange_init() assumes that start and end are both multiples of
PMD_SIZE, which is not true, to put it mildly.  Wraparounds are possible
there - e.g. I've seen it called with 0xfffe000/0xffff000 for 32bit UML
running on amd64 host.  Not pretty, since vaddr < end will always remain
true when called that way.  With 3-level pagetables it gets really ugly -
it's nowhere near the end of upper-level table yet, so i < PTRS_PER_PGD
also doesn't stop the sucker.  I think the right solution here is to shift
vaddr down by PMD_SHIFT and do the same to end (taking care of fencepost
errors, of course).
	* no biarch support; that one might be really painful to implement,
but if we want it on something like ppc64 or sparc64 where the userland
is routinely 32bit...  That's going to be really rough on mm-switching
variants, BTW - when kernel address space is 64bit one and userland ones
are 32bit... <shudder>

	Anyway, I'm back to pure VFS work for the next few weeks.  I'll
probably dump fixrange_init() fixes into this tree, but anything beyond
that will have to wait until I dig myself out of atomic_open work and
unionfs/overlayfs/aufs/whatnot mess...