From: David W. <dw...@in...> - 2011-07-30 23:54:40
|
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 <Dav...@in...> --- 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 |
From: David W. <dw...@in...> - 2011-07-30 23:54:49
|
If we're in Makefile-i386, we know what the target architecture is. Don't try to be cute. Signed-off-by: David Woodhouse <Dav...@in...> --- 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 |
From: David W. <dw...@in...> - 2011-07-30 23:54:57
|
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 <Dav...@in...> --- 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 |
From: David W. <dw...@in...> - 2011-07-30 23:55:04
|
If the compiler doesn't understand it, cc-option will deal with that. Signed-off-by: David Woodhouse <Dav...@in...> --- 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 |
From: David W. <dw...@in...> - 2011-07-30 23:55:11
|
Signed-off-by: David Woodhouse <Dav...@in...> --- 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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-09 23:38:42
|
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... |
From: richard -r. w. <ric...@gm...> - 2011-07-31 22:11:14
|
On Sun, Jul 31, 2011 at 1:02 AM, David Woodhouse <dw...@in...> wrote: > Signed-off-by: David Woodhouse <Dav...@in...> > --- > 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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-10 04:04:57
|
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... |
From: David W. <dw...@in...> - 2011-07-31 22:24:34
|
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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-10 17:44:43
|
> 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... |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-11 04:23:36
|
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). |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-07-31 22:48:46
|
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/ |
From: David W. <dw...@in...> - 2011-07-31 23:09:32
|
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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-07-31 22:58:13
|
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). |
From: richard -r. w. <ric...@gm...> - 2011-08-11 12:13:28
|
On Thu, Aug 11, 2011 at 6:23 AM, Al Viro <vi...@ze...> 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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-11 14:05:41
|
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... |
From: David W. <dw...@in...> - 2011-07-31 23:13:18
|
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 |
From: richard -r. w. <ric...@gm...> - 2011-07-31 23:17:23
|
On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dw...@in...> 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 |
From: David W. <dw...@in...> - 2011-07-31 23:24:22
|
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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-01 04:32:20
|
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 <dw...@in...> 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. |
From: Geert U. <ge...@li...> - 2011-08-01 10:04:46
|
On Mon, Aug 1, 2011 at 06:32, Al Viro <vi...@ze...> 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 <dw...@in...> 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 -- ge...@li... 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 |
From: richard -r. w. <ric...@gm...> - 2011-08-01 10:40:59
|
On Mon, Aug 1, 2011 at 12:04 PM, Geert Uytterhoeven <ge...@li...> 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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2011-08-01 17:23:13
|
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... |
From: richard -r. w. <ric...@gm...> - 2011-08-01 17:52:42
|
On Mon, Aug 1, 2011 at 6:32 AM, Al Viro <vi...@ze...> 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 |