Re: [x86 patch] Fix UML signal.h build errors
On Sat, Oct 27, 2007 at 11:35:10AM +0530, Balbir Singh wrote: > > b) I'd rather have __arch_um__ mentioned explicitly in 3 places where > > we do care about difference between i386 and uml/i386 than have certain > > to be forgotten rules for places like include/asm-x86 > > > > c) if you look at those places, you'll see > > * drivers/char/mem.c::uncached_access(). Really per-architecture > > and I wonder if it might be include/asm-* fodder... > > * kernel/signal.c debugging printks. Should die or be sanitized, IMO. > > * raid6 algorithms. Hell knows - immediate reason why we don't do > > those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and > > boot_cpu_has(), but that's easier to add). Do we care to implement that > > stuff? > I suspect that list might grow and anybody writing i386 or x86_64 code > will need to double check if the code will work under __arch_um__. > Probably worth documenting somewhere. For x86-only code it's not really a problem - i.e. if we pull it into uml build at all, checks for BITS_PER_LONG/__i386__/CONFIG_64BIT/etc. are all the same. For arch-dependent drivers... we have very good reasons not pull them into uml builds anyway. And arch-independent code shouldn't care at all, so we are left with random bits of arch-dependent code ifdefed in generic one _and_ not handled via asm/*.h. I.e. with very few odd cases - it's not that we wanted to add and keep such places anyway, uml or no uml. I'd say that raid6 is the only legitimate current case and even that is somewhat dubious - we might e.g. not bother with x86-only parts of raid456-objs on other targets and handle that on Kconfig/Makefile level. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
Al Viro wrote: > On Thu, Oct 25, 2007 at 09:01:52PM +0530, Balbir Singh wrote: > >> Thats nice, I wonder why I missed them searching on lkml in my gmail box >> :( >> >> Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer >> BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). >> I guess its a matter of personal preference. > > Huh? > > a) we really shouldn't mess with compiler defines (i.e. we should not > undef __i386__ or __x86_64__) > I agree > b) I'd rather have __arch_um__ mentioned explicitly in 3 places where > we do care about difference between i386 and uml/i386 than have certain > to be forgotten rules for places like include/asm-x86 > > c) if you look at those places, you'll see > * drivers/char/mem.c::uncached_access(). Really per-architecture > and I wonder if it might be include/asm-* fodder... > * kernel/signal.c debugging printks. Should die or be sanitized, IMO. > * raid6 algorithms. Hell knows - immediate reason why we don't do > those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and > boot_cpu_has(), but that's easier to add). Do we care to implement that > stuff? > I suspect that list might grow and anybody writing i386 or x86_64 code will need to double check if the code will work under __arch_um__. Probably worth documenting somewhere. > That's _all_. Nothing else has to care. > :-) -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
Al Viro wrote: On Thu, Oct 25, 2007 at 09:01:52PM +0530, Balbir Singh wrote: Thats nice, I wonder why I missed them searching on lkml in my gmail box :( Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). I guess its a matter of personal preference. Huh? a) we really shouldn't mess with compiler defines (i.e. we should not undef __i386__ or __x86_64__) I agree b) I'd rather have __arch_um__ mentioned explicitly in 3 places where we do care about difference between i386 and uml/i386 than have certain to be forgotten rules for places like include/asm-x86 c) if you look at those places, you'll see * drivers/char/mem.c::uncached_access(). Really per-architecture and I wonder if it might be include/asm-* fodder... * kernel/signal.c debugging printks. Should die or be sanitized, IMO. * raid6 algorithms. Hell knows - immediate reason why we don't do those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and boot_cpu_has(), but that's easier to add). Do we care to implement that stuff? I suspect that list might grow and anybody writing i386 or x86_64 code will need to double check if the code will work under __arch_um__. Probably worth documenting somewhere. That's _all_. Nothing else has to care. :-) -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
On Sat, Oct 27, 2007 at 11:35:10AM +0530, Balbir Singh wrote: b) I'd rather have __arch_um__ mentioned explicitly in 3 places where we do care about difference between i386 and uml/i386 than have certain to be forgotten rules for places like include/asm-x86 c) if you look at those places, you'll see * drivers/char/mem.c::uncached_access(). Really per-architecture and I wonder if it might be include/asm-* fodder... * kernel/signal.c debugging printks. Should die or be sanitized, IMO. * raid6 algorithms. Hell knows - immediate reason why we don't do those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and boot_cpu_has(), but that's easier to add). Do we care to implement that stuff? I suspect that list might grow and anybody writing i386 or x86_64 code will need to double check if the code will work under __arch_um__. Probably worth documenting somewhere. For x86-only code it's not really a problem - i.e. if we pull it into uml build at all, checks for BITS_PER_LONG/__i386__/CONFIG_64BIT/etc. are all the same. For arch-dependent drivers... we have very good reasons not pull them into uml builds anyway. And arch-independent code shouldn't care at all, so we are left with random bits of arch-dependent code ifdefed in generic one _and_ not handled via asm/*.h. I.e. with very few odd cases - it's not that we wanted to add and keep such places anyway, uml or no uml. I'd say that raid6 is the only legitimate current case and even that is somewhat dubious - we might e.g. not bother with x86-only parts of raid456-objs on other targets and handle that on Kconfig/Makefile level. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
On Thu, Oct 25, 2007 at 09:01:52PM +0530, Balbir Singh wrote: > Thats nice, I wonder why I missed them searching on lkml in my gmail box > :( > > Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer > BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). > I guess its a matter of personal preference. Huh? a) we really shouldn't mess with compiler defines (i.e. we should not undef __i386__ or __x86_64__) b) I'd rather have __arch_um__ mentioned explicitly in 3 places where we do care about difference between i386 and uml/i386 than have certain to be forgotten rules for places like include/asm-x86 c) if you look at those places, you'll see * drivers/char/mem.c::uncached_access(). Really per-architecture and I wonder if it might be include/asm-* fodder... * kernel/signal.c debugging printks. Should die or be sanitized, IMO. * raid6 algorithms. Hell knows - immediate reason why we don't do those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and boot_cpu_has(), but that's easier to add). Do we care to implement that stuff? That's _all_. Nothing else has to care. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
On Thu, Oct 25, 2007 at 09:01:52PM +0530, Balbir Singh wrote: Thats nice, I wonder why I missed them searching on lkml in my gmail box :( Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). I guess its a matter of personal preference. Huh? a) we really shouldn't mess with compiler defines (i.e. we should not undef __i386__ or __x86_64__) b) I'd rather have __arch_um__ mentioned explicitly in 3 places where we do care about difference between i386 and uml/i386 than have certain to be forgotten rules for places like include/asm-x86 c) if you look at those places, you'll see * drivers/char/mem.c::uncached_access(). Really per-architecture and I wonder if it might be include/asm-* fodder... * kernel/signal.c debugging printks. Should die or be sanitized, IMO. * raid6 algorithms. Hell knows - immediate reason why we don't do those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and boot_cpu_has(), but that's easier to add). Do we care to implement that stuff? That's _all_. Nothing else has to care. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
Jeff Dike wrote: > On Thu, Oct 25, 2007 at 06:30:22PM +0530, Balbir Singh wrote: >> Fix build errors seen in UML. > > Al fixed these already. > > FWIW, below is a rolled-up combo patch which make 2.6.24-rc1 UML build. > > It includes Al's build fixes, Wang Cong's driver fix, and a declaration > mismatch in sched.c. > > Jeff > Thats nice, I wonder why I missed them searching on lkml in my gmail box :( Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). I guess its a matter of personal preference. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86 patch] Fix UML signal.h build errors
On Thu, Oct 25, 2007 at 06:30:22PM +0530, Balbir Singh wrote:
> Fix build errors seen in UML.
Al fixed these already.
FWIW, below is a rolled-up combo patch which make 2.6.24-rc1 UML build.
It includes Al's build fixes, Wang Cong's driver fix, and a declaration
mismatch in sched.c.
Jeff
--
Work email - jdike at linux dot intel dot com
Index: linux-2.6.17/arch/um/Makefile
===
--- linux-2.6.17.orig/arch/um/Makefile 2007-10-24 10:04:50.0 -0400
+++ linux-2.6.17/arch/um/Makefile 2007-10-24 10:19:58.0 -0400
@@ -70,9 +70,12 @@ include $(srctree)/$(ARCH_DIR)/Makefile-
# in KBUILD_CFLAGS. Otherwise, it would cause ld to complain about the two
different
# errnos.
# These apply to kernelspace only.
+#
+# strip leading and trailing whitespace to make the USER_CFLAGS removal of
these
+# defines more robust
-KERNEL_DEFINES = -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \
- -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES)
+KERNEL_DEFINES = $(strip -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask
\
+-Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES))
KBUILD_CFLAGS += $(KERNEL_DEFINES)
KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time,)
Index: linux-2.6.17/arch/um/Makefile-i386
===
--- linux-2.6.17.orig/arch/um/Makefile-i386 2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/arch/um/Makefile-i386 2007-10-24 10:16:51.0 -0400
@@ -9,6 +9,7 @@ ELF_ARCH:= $(SUBARCH)
ELF_FORMAT := elf32-$(SUBARCH)
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)")
@@ -26,8 +27,6 @@ AFLAGS+= -DCONFIG_X86_32
CONFIG_X86_32 := y
export CONFIG_X86_32
-ARCH_KERNEL_DEFINES += -U__$(SUBARCH)__ -U$(SUBARCH)
-
# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
include $(srctree)/arch/i386/Makefile.cpu
Index: linux-2.6.17/arch/um/Makefile-x86_64
===
--- linux-2.6.17.orig/arch/um/Makefile-x86_64 2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/arch/um/Makefile-x86_642007-10-24 10:16:51.0
-0400
@@ -6,12 +6,9 @@ START := 0x6000
_extra_flags_ = -fno-builtin -m64
-#We #undef __x86_64__ for kernelspace, not for userspace where
-#it's needed for headers to work!
-ARCH_KERNEL_DEFINES = -U__$(SUBARCH)__
KBUILD_CFLAGS += $(_extra_flags_)
-CHECKFLAGS += -m64
+CHECKFLAGS += -m64 -D__x86_64__
KBUILD_AFLAGS += -m64
LDFLAGS += -m elf_x86_64
KBUILD_CPPFLAGS += -m64
Index: linux-2.6.17/arch/um/kernel/sysrq.c
===
--- linux-2.6.17.orig/arch/um/kernel/sysrq.c2007-07-09 08:53:09.0
-0400
+++ linux-2.6.17/arch/um/kernel/sysrq.c 2007-10-24 10:16:51.0 -0400
@@ -8,6 +8,7 @@
#include "linux/module.h"
#include "linux/kallsyms.h"
#include "asm/page.h"
+#include "registers.h"
#include "asm/processor.h"
#include "sysrq.h"
Index: linux-2.6.17/drivers/char/mem.c
===
--- linux-2.6.17.orig/drivers/char/mem.c2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/drivers/char/mem.c 2007-10-24 10:16:51.0 -0400
@@ -41,7 +41,7 @@
*/
static inline int uncached_access(struct file *file, unsigned long addr)
{
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
/*
* On the PPro and successors, the MTRRs are used to set
* memory types for physical addresses outside main memory,
@@ -57,7 +57,7 @@ static inline int uncached_access(struct
test_bit(X86_FEATURE_CYRIX_ARR, boot_cpu_data.x86_capability)
||
test_bit(X86_FEATURE_CENTAUR_MCR,
boot_cpu_data.x86_capability) )
&& addr >= __pa(high_memory);
-#elif defined(__x86_64__)
+#elif defined(__x86_64__) && !defined(__arch_um__)
/*
* This is broken because it can generate memory type aliases,
* which can cause cache corruptions
Index: linux-2.6.17/drivers/md/raid6algos.c
===
--- linux-2.6.17.orig/drivers/md/raid6algos.c 2006-10-20 13:41:41.0
-0400
+++ linux-2.6.17/drivers/md/raid6algos.c2007-10-24 10:16:51.0
-0400
@@ -52,7 +52,7 @@ const struct raid6_calls * const raid6_a
_intx16,
_intx32,
#endif
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
_mmxx1,
_mmxx2,
_sse1x1,
@@ -60,7 +60,7 @@ const struct raid6_calls * const raid6_a
_sse2x1,
_sse2x2,
#endif
-#if
Re: [x86 patch] Fix UML signal.h build errors
On Thu, Oct 25, 2007 at 06:30:22PM +0530, Balbir Singh wrote:
Fix build errors seen in UML.
Al fixed these already.
FWIW, below is a rolled-up combo patch which make 2.6.24-rc1 UML build.
It includes Al's build fixes, Wang Cong's driver fix, and a declaration
mismatch in sched.c.
Jeff
--
Work email - jdike at linux dot intel dot com
Index: linux-2.6.17/arch/um/Makefile
===
--- linux-2.6.17.orig/arch/um/Makefile 2007-10-24 10:04:50.0 -0400
+++ linux-2.6.17/arch/um/Makefile 2007-10-24 10:19:58.0 -0400
@@ -70,9 +70,12 @@ include $(srctree)/$(ARCH_DIR)/Makefile-
# in KBUILD_CFLAGS. Otherwise, it would cause ld to complain about the two
different
# errnos.
# These apply to kernelspace only.
+#
+# strip leading and trailing whitespace to make the USER_CFLAGS removal of
these
+# defines more robust
-KERNEL_DEFINES = -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \
- -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES)
+KERNEL_DEFINES = $(strip -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask
\
+-Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES))
KBUILD_CFLAGS += $(KERNEL_DEFINES)
KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time,)
Index: linux-2.6.17/arch/um/Makefile-i386
===
--- linux-2.6.17.orig/arch/um/Makefile-i386 2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/arch/um/Makefile-i386 2007-10-24 10:16:51.0 -0400
@@ -9,6 +9,7 @@ ELF_ARCH:= $(SUBARCH)
ELF_FORMAT := elf32-$(SUBARCH)
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))
@@ -26,8 +27,6 @@ AFLAGS+= -DCONFIG_X86_32
CONFIG_X86_32 := y
export CONFIG_X86_32
-ARCH_KERNEL_DEFINES += -U__$(SUBARCH)__ -U$(SUBARCH)
-
# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
include $(srctree)/arch/i386/Makefile.cpu
Index: linux-2.6.17/arch/um/Makefile-x86_64
===
--- linux-2.6.17.orig/arch/um/Makefile-x86_64 2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/arch/um/Makefile-x86_642007-10-24 10:16:51.0
-0400
@@ -6,12 +6,9 @@ START := 0x6000
_extra_flags_ = -fno-builtin -m64
-#We #undef __x86_64__ for kernelspace, not for userspace where
-#it's needed for headers to work!
-ARCH_KERNEL_DEFINES = -U__$(SUBARCH)__
KBUILD_CFLAGS += $(_extra_flags_)
-CHECKFLAGS += -m64
+CHECKFLAGS += -m64 -D__x86_64__
KBUILD_AFLAGS += -m64
LDFLAGS += -m elf_x86_64
KBUILD_CPPFLAGS += -m64
Index: linux-2.6.17/arch/um/kernel/sysrq.c
===
--- linux-2.6.17.orig/arch/um/kernel/sysrq.c2007-07-09 08:53:09.0
-0400
+++ linux-2.6.17/arch/um/kernel/sysrq.c 2007-10-24 10:16:51.0 -0400
@@ -8,6 +8,7 @@
#include linux/module.h
#include linux/kallsyms.h
#include asm/page.h
+#include registers.h
#include asm/processor.h
#include sysrq.h
Index: linux-2.6.17/drivers/char/mem.c
===
--- linux-2.6.17.orig/drivers/char/mem.c2007-10-24 10:04:50.0
-0400
+++ linux-2.6.17/drivers/char/mem.c 2007-10-24 10:16:51.0 -0400
@@ -41,7 +41,7 @@
*/
static inline int uncached_access(struct file *file, unsigned long addr)
{
-#if defined(__i386__)
+#if defined(__i386__) !defined(__arch_um__)
/*
* On the PPro and successors, the MTRRs are used to set
* memory types for physical addresses outside main memory,
@@ -57,7 +57,7 @@ static inline int uncached_access(struct
test_bit(X86_FEATURE_CYRIX_ARR, boot_cpu_data.x86_capability)
||
test_bit(X86_FEATURE_CENTAUR_MCR,
boot_cpu_data.x86_capability) )
addr = __pa(high_memory);
-#elif defined(__x86_64__)
+#elif defined(__x86_64__) !defined(__arch_um__)
/*
* This is broken because it can generate memory type aliases,
* which can cause cache corruptions
Index: linux-2.6.17/drivers/md/raid6algos.c
===
--- linux-2.6.17.orig/drivers/md/raid6algos.c 2006-10-20 13:41:41.0
-0400
+++ linux-2.6.17/drivers/md/raid6algos.c2007-10-24 10:16:51.0
-0400
@@ -52,7 +52,7 @@ const struct raid6_calls * const raid6_a
raid6_intx16,
raid6_intx32,
#endif
-#if defined(__i386__)
+#if defined(__i386__) !defined(__arch_um__)
raid6_mmxx1,
raid6_mmxx2,
raid6_sse1x1,
@@ -60,7 +60,7 @@ const struct raid6_calls * const raid6_a
raid6_sse2x1,
raid6_sse2x2,
#endif
-#if
Re: [x86 patch] Fix UML signal.h build errors
Jeff Dike wrote: On Thu, Oct 25, 2007 at 06:30:22PM +0530, Balbir Singh wrote: Fix build errors seen in UML. Al fixed these already. FWIW, below is a rolled-up combo patch which make 2.6.24-rc1 UML build. It includes Al's build fixes, Wang Cong's driver fix, and a declaration mismatch in sched.c. Jeff Thats nice, I wonder why I missed them searching on lkml in my gmail box :( Is __arch_um__ the right thing to do or BITS_PER_LONG == 32? I prefer BITS_PER_LONG == 32 over #if defined(__i386__) || defined(__arch__um__). I guess its a matter of personal preference. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
