All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] finish processor.h integration
@ 2007-12-18 20:04 ` Glauber de Oliveira Costa
  0 siblings, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-18 20:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: ehabkost, ak, virtualization, chrisw, tglx, anthony, hpa, akpm,
	Glauber de Oliveira Costa, mingo, roland

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
---
 include/asm-x86/processor.h |  140 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 137 insertions(+), 3 deletions(-)

diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h
index 80c5002..0641d0e 100644
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
 struct task_struct;
 struct mm_struct;
 
+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
 #include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
 #include <asm/system.h>
+#include <asm/page.h>
 #include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
 #include <linux/cpumask.h>
 #include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>
 
 /*
  * Default implementation of macro that returns current
@@ -275,7 +287,11 @@ union i387_union {
 	struct i387_soft_struct soft;
 };
 
-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern	int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
 #else
 struct i387_fxsave_struct {
 	u16	cwd;
@@ -295,7 +311,7 @@ union i387_union {
 	struct i387_fxsave_struct	fxsave;
 };
 
-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
 #endif
 
 extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -778,6 +794,124 @@ static inline void prefetchw(const void *x)
 }
 
 #define spin_lock_prefetch(x)	prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE	(PAGE_OFFSET)
+
+#define INIT_THREAD  {							\
+	.sp0 = sizeof(init_stack) + (long)&init_stack,			\
+	.vm86_info = NULL,						\
+	.sysenter_cs = __KERNEL_CS,					\
+	.io_bitmap_ptr = NULL,						\
+	.fs = __KERNEL_PERCPU,						\
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS  {							\
+	.x86_tss = {							\
+		.sp0		= sizeof(init_stack) + (long)&init_stack, \
+		.ss0		= __KERNEL_DS,				\
+		.ss1		= __KERNEL_CS,				\
+		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		\
+	 },								\
+	.io_bitmap	= { [0 ... IO_BITMAP_LONGS] = ~0 },		\
+}
+
+#define start_thread(regs, new_eip, new_esp) do {		\
+	__asm__("movl %0,%%gs": :"r" (0));			\
+	regs->fs = 0;						\
+	set_fs(USER_DS);					\
+	regs->ds = __USER_DS;					\
+	regs->es = __USER_DS;					\
+	regs->ss = __USER_DS;					\
+	regs->cs = __USER_CS;					\
+	regs->ip = new_eip;					\
+	regs->sp = new_esp;					\
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS      (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info)                                                 \
+({                                                                     \
+       unsigned long *__ptr = (unsigned long *)(info);                 \
+       (unsigned long)(&__ptr[THREAD_SIZE_LONGS]);                     \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task)                                             \
+({                                                                     \
+       struct pt_regs *__regs__;                                       \
+       __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+       __regs__ - 1;                                                   \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64	(0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+			   0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE 		(test_thread_flag(TIF_IA32) ? \
+				 IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) 	((test_tsk_thread_flag(child, TIF_IA32)) ? \
+				  IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD  { \
+	.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS  { \
+	.x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { 			     \
+	asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0));  \
+	load_gs_index(0);						     \
+	(regs)->ip = (new_rip);						     \
+	(regs)->sp = (new_rsp);						     \
+	write_pda(oldrsp, (new_rsp));					     \
+	(regs)->cs = __USER_CS;						     \
+	(regs)->ss = __USER_DS;						     \
+	(regs)->flags = 0x200;						     \
+	set_fs(USER_DS);						     \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */
-- 
1.5.0.6

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] finish processor.h integration
@ 2007-12-18 20:04 ` Glauber de Oliveira Costa
  0 siblings, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-18 20:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: akpm, glommer, tglx, mingo, ehabkost, jeremy, avi, anthony,
	virtualization, rusty, ak, chrisw, rostedt, hpa, zach, roland,
	Glauber de Oliveira Costa

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
---
 include/asm-x86/processor.h |  140 ++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 137 insertions(+), 3 deletions(-)

diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h
index 80c5002..0641d0e 100644
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
 struct task_struct;
 struct mm_struct;
 
+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
 #include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
 #include <asm/system.h>
+#include <asm/page.h>
 #include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
 #include <linux/cpumask.h>
 #include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>
 
 /*
  * Default implementation of macro that returns current
@@ -275,7 +287,11 @@ union i387_union {
 	struct i387_soft_struct soft;
 };
 
-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern	int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
 #else
 struct i387_fxsave_struct {
 	u16	cwd;
@@ -295,7 +311,7 @@ union i387_union {
 	struct i387_fxsave_struct	fxsave;
 };
 
-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
 #endif
 
 extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -778,6 +794,124 @@ static inline void prefetchw(const void *x)
 }
 
 #define spin_lock_prefetch(x)	prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE	(PAGE_OFFSET)
+
+#define INIT_THREAD  {							\
+	.sp0 = sizeof(init_stack) + (long)&init_stack,			\
+	.vm86_info = NULL,						\
+	.sysenter_cs = __KERNEL_CS,					\
+	.io_bitmap_ptr = NULL,						\
+	.fs = __KERNEL_PERCPU,						\
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS  {							\
+	.x86_tss = {							\
+		.sp0		= sizeof(init_stack) + (long)&init_stack, \
+		.ss0		= __KERNEL_DS,				\
+		.ss1		= __KERNEL_CS,				\
+		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		\
+	 },								\
+	.io_bitmap	= { [0 ... IO_BITMAP_LONGS] = ~0 },		\
+}
+
+#define start_thread(regs, new_eip, new_esp) do {		\
+	__asm__("movl %0,%%gs": :"r" (0));			\
+	regs->fs = 0;						\
+	set_fs(USER_DS);					\
+	regs->ds = __USER_DS;					\
+	regs->es = __USER_DS;					\
+	regs->ss = __USER_DS;					\
+	regs->cs = __USER_CS;					\
+	regs->ip = new_eip;					\
+	regs->sp = new_esp;					\
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS      (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info)                                                 \
+({                                                                     \
+       unsigned long *__ptr = (unsigned long *)(info);                 \
+       (unsigned long)(&__ptr[THREAD_SIZE_LONGS]);                     \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task)                                             \
+({                                                                     \
+       struct pt_regs *__regs__;                                       \
+       __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+       __regs__ - 1;                                                   \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64	(0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+			   0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE 		(test_thread_flag(TIF_IA32) ? \
+				 IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) 	((test_tsk_thread_flag(child, TIF_IA32)) ? \
+				  IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD  { \
+	.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS  { \
+	.x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { 			     \
+	asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0));  \
+	load_gs_index(0);						     \
+	(regs)->ip = (new_rip);						     \
+	(regs)->sp = (new_rsp);						     \
+	write_pda(oldrsp, (new_rsp));					     \
+	(regs)->cs = __USER_CS;						     \
+	(regs)->ss = __USER_DS;						     \
+	(regs)->flags = 0x200;						     \
+	set_fs(USER_DS);						     \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */
-- 
1.5.0.6


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:04 ` Glauber de Oliveira Costa
  (?)
  (?)
@ 2007-12-18 20:54 ` Frans Pop
  -1 siblings, 0 replies; 18+ messages in thread
From: Frans Pop @ 2007-12-18 20:54 UTC (permalink / raw)
  Cc: tglx, ehabkost, ak, gcosta, chrisw, roland, anthony, hpa, akpm,
	virtualization, mingo, linux-kernel

Glauber de Oliveira Costa wrote:
> What's left in processor_32.h and processor_64.h cannot be cleanly
> integrated. However, it's just a couple of definitions. They are moved
> to processor.h around ifdefs, and the original files are deleted. Note
> that there's much less headers included in the final version.

Either I must be missing something or this patch was corrupted somehow.

I see:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_64 */

While I'd have expected:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_32 */
+
+#ifdef CONFIG_X86_64
[...]
+#endif /* CONFIG_X86_64 */

Cheers,
FJP

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:04 ` Glauber de Oliveira Costa
  (?)
@ 2007-12-18 20:54 ` Frans Pop
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  -1 siblings, 2 replies; 18+ messages in thread
From: Frans Pop @ 2007-12-18 20:54 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: ak, akpm, anthony, avi, chrisw, ehabkost, gcosta, glommer, hpa,
	jeremy, linux-kernel, mingo, roland, rostedt, rusty, tglx,
	virtualization, zach

Glauber de Oliveira Costa wrote:
> What's left in processor_32.h and processor_64.h cannot be cleanly
> integrated. However, it's just a couple of definitions. They are moved
> to processor.h around ifdefs, and the original files are deleted. Note
> that there's much less headers included in the final version.

Either I must be missing something or this patch was corrupted somehow.

I see:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_64 */

While I'd have expected:

+#ifdef CONFIG_X86_32
[...]
+#endif /* CONFIG_X86_32 */
+
+#ifdef CONFIG_X86_64
[...]
+#endif /* CONFIG_X86_64 */

Cheers,
FJP

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:54 ` Frans Pop
@ 2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  1 sibling, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-18 21:00 UTC (permalink / raw)
  To: Frans Pop
  Cc: ehabkost, linux-kernel, ak, Glauber de Oliveira Costa, chrisw,
	tglx, anthony, hpa, akpm, virtualization, mingo, roland

On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> Glauber de Oliveira Costa wrote:
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> Either I must be missing something or this patch was corrupted somehow.

neither.
Note the else in the middle. It's just a mistake in the comment.
Ingo, do you want me to send an update with it ?

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:54 ` Frans Pop
  2007-12-18 21:00   ` Glauber de Oliveira Costa
@ 2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-18 21:02     ` Ingo Molnar
                       ` (3 more replies)
  1 sibling, 4 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-18 21:00 UTC (permalink / raw)
  To: Frans Pop
  Cc: Glauber de Oliveira Costa, ak, akpm, anthony, avi, chrisw,
	ehabkost, hpa, jeremy, linux-kernel, mingo, roland, rostedt,
	rusty, tglx, virtualization, zach

On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> Glauber de Oliveira Costa wrote:
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> Either I must be missing something or this patch was corrupted somehow.

neither.
Note the else in the middle. It's just a mistake in the comment.
Ingo, do you want me to send an update with it ?

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-18 21:02     ` Ingo Molnar
@ 2007-12-18 21:02     ` Ingo Molnar
  2007-12-18 21:32     ` Frans Pop
  2007-12-18 21:32     ` Frans Pop
  3 siblings, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-18 21:02 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: ehabkost, linux-kernel, Frans Pop, ak, Glauber de Oliveira Costa,
	chrisw, anthony, hpa, akpm, virtualization, tglx, roland


* Glauber de Oliveira Costa <glommer@gmail.com> wrote:

> On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are moved
> > > to processor.h around ifdefs, and the original files are deleted. Note
> > > that there's much less headers included in the final version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
> 
> neither.
> Note the else in the middle. It's just a mistake in the comment.
> Ingo, do you want me to send an update with it ?

no need, i'll pick up the current patches.

	Ingo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:00   ` Glauber de Oliveira Costa
@ 2007-12-18 21:02     ` Ingo Molnar
  2007-12-18 21:02     ` Ingo Molnar
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-18 21:02 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: Frans Pop, Glauber de Oliveira Costa, ak, akpm, anthony, avi,
	chrisw, ehabkost, hpa, jeremy, linux-kernel, roland, rostedt,
	rusty, tglx, virtualization, zach


* Glauber de Oliveira Costa <glommer@gmail.com> wrote:

> On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are moved
> > > to processor.h around ifdefs, and the original files are deleted. Note
> > > that there's much less headers included in the final version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
> 
> neither.
> Note the else in the middle. It's just a mistake in the comment.
> Ingo, do you want me to send an update with it ?

no need, i'll pick up the current patches.

	Ingo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:00   ` Glauber de Oliveira Costa
                       ` (2 preceding siblings ...)
  2007-12-18 21:32     ` Frans Pop
@ 2007-12-18 21:32     ` Frans Pop
  3 siblings, 0 replies; 18+ messages in thread
From: Frans Pop @ 2007-12-18 21:32 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: ehabkost, linux-kernel, ak, Glauber de Oliveira Costa, chrisw,
	tglx, anthony, hpa, akpm, virtualization, mingo, roland

On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are
> > > moved to processor.h around ifdefs, and the original files are
> > > deleted. Note that there's much less headers included in the final
> > > version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
>
> neither.
> Note the else in the middle. It's just a mistake in the comment.

Wouldn't an explicit second #ifdef block be a lot clearer (and improve 
maintainability) in this case?

An #else can easily be overlooked among other preprocessor commands or when 
#ifdefs get nested.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-18 21:02     ` Ingo Molnar
  2007-12-18 21:02     ` Ingo Molnar
@ 2007-12-18 21:32     ` Frans Pop
  2007-12-19  2:56       ` Glauber de Oliveira Costa
  2007-12-19  2:56       ` Glauber de Oliveira Costa
  2007-12-18 21:32     ` Frans Pop
  3 siblings, 2 replies; 18+ messages in thread
From: Frans Pop @ 2007-12-18 21:32 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: Glauber de Oliveira Costa, ak, akpm, anthony, avi, chrisw,
	ehabkost, hpa, jeremy, linux-kernel, mingo, roland, rostedt,
	rusty, tglx, virtualization, zach

On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > Glauber de Oliveira Costa wrote:
> > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > integrated. However, it's just a couple of definitions. They are
> > > moved to processor.h around ifdefs, and the original files are
> > > deleted. Note that there's much less headers included in the final
> > > version.
> >
> > Either I must be missing something or this patch was corrupted somehow.
>
> neither.
> Note the else in the middle. It's just a mistake in the comment.

Wouldn't an explicit second #ifdef block be a lot clearer (and improve 
maintainability) in this case?

An #else can easily be overlooked among other preprocessor commands or when 
#ifdefs get nested.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:32     ` Frans Pop
  2007-12-19  2:56       ` Glauber de Oliveira Costa
@ 2007-12-19  2:56       ` Glauber de Oliveira Costa
  1 sibling, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-19  2:56 UTC (permalink / raw)
  To: Frans Pop
  Cc: ehabkost, linux-kernel, ak, Glauber de Oliveira Costa, chrisw,
	tglx, anthony, hpa, akpm, virtualization, mingo, roland

On Dec 18, 2007 7:32 PM, Frans Pop <elendil@planet.nl> wrote:
> On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> > On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > > Glauber de Oliveira Costa wrote:
> > > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > > integrated. However, it's just a couple of definitions. They are
> > > > moved to processor.h around ifdefs, and the original files are
> > > > deleted. Note that there's much less headers included in the final
> > > > version.
> > >
> > > Either I must be missing something or this patch was corrupted somehow.
> >
> > neither.
> > Note the else in the middle. It's just a mistake in the comment.
>
> Wouldn't an explicit second #ifdef block be a lot clearer (and improve
> maintainability) in this case?
>
> An #else can easily be overlooked among other preprocessor commands or when
> #ifdefs get nested.
>
I don't think so. a if-then-else kind of construction is very common,
well expected, and heavily used in kernel.
But even if I´m not right, this is functionally correct, and can be
addressed in a later cleanup patch if you really want to.


-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 21:32     ` Frans Pop
@ 2007-12-19  2:56       ` Glauber de Oliveira Costa
  2007-12-19  2:56       ` Glauber de Oliveira Costa
  1 sibling, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-19  2:56 UTC (permalink / raw)
  To: Frans Pop
  Cc: Glauber de Oliveira Costa, ak, akpm, anthony, avi, chrisw,
	ehabkost, hpa, jeremy, linux-kernel, mingo, roland, rostedt,
	rusty, tglx, virtualization, zach

On Dec 18, 2007 7:32 PM, Frans Pop <elendil@planet.nl> wrote:
> On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
> > On Dec 18, 2007 6:54 PM, Frans Pop <elendil@planet.nl> wrote:
> > > Glauber de Oliveira Costa wrote:
> > > > What's left in processor_32.h and processor_64.h cannot be cleanly
> > > > integrated. However, it's just a couple of definitions. They are
> > > > moved to processor.h around ifdefs, and the original files are
> > > > deleted. Note that there's much less headers included in the final
> > > > version.
> > >
> > > Either I must be missing something or this patch was corrupted somehow.
> >
> > neither.
> > Note the else in the middle. It's just a mistake in the comment.
>
> Wouldn't an explicit second #ifdef block be a lot clearer (and improve
> maintainability) in this case?
>
> An #else can easily be overlooked among other preprocessor commands or when
> #ifdefs get nested.
>
I don't think so. a if-then-else kind of construction is very common,
well expected, and heavily used in kernel.
But even if I´m not right, this is functionally correct, and can be
addressed in a later cleanup patch if you really want to.


-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:04 ` Glauber de Oliveira Costa
@ 2007-12-19 10:17   ` Ingo Molnar
  -1 siblings, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-19 10:17 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: ehabkost, linux-kernel, virtualization, chrisw, anthony, hpa,
	akpm, tglx, roland, ak


* Glauber de Oliveira Costa <gcosta@redhat.com> wrote:

> What's left in processor_32.h and processor_64.h cannot be cleanly 
> integrated. However, it's just a couple of definitions. They are moved 
> to processor.h around ifdefs, and the original files are deleted. Note 
> that there's much less headers included in the final version.

hm, doesnt apply;

 Applying patch patches/x86-finish-processor-h-integration.patch
 patching file include/asm-x86/processor.h
 Hunk #2 FAILED at 287.
 Hunk #3 FAILED at 311.
 Hunk #4 succeeded at 786 (offset -8 lines).
 2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h

i fixed it up by hand - the result is below - does it look OK to you? 
(Also, could you check latest x86.git whether i've picked up all your 
patches correctly - the reject might be indicative of some missing 
pieces.)

	Ingo

------------>
Subject: finish processor.h integration
From: Glauber de Oliveira Costa <gcosta@redhat.com>

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/asm-x86/processor.h |  140 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 137 insertions(+), 3 deletions(-)

Index: linux-x86.q/include/asm-x86/processor.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/processor.h
+++ linux-x86.q/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
 struct task_struct;
 struct mm_struct;
 
+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
 #include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
 #include <asm/system.h>
+#include <asm/page.h>
 #include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
 #include <linux/cpumask.h>
 #include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>
 
 /*
  * Default implementation of macro that returns current
@@ -285,9 +297,13 @@ union i387_union {
 };
 
 #ifdef CONFIG_X86_32
-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern	int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
 #else
-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
 #endif
 
 extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -770,6 +786,124 @@ static inline void prefetchw(const void 
 }
 
 #define spin_lock_prefetch(x)	prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE	(PAGE_OFFSET)
+
+#define INIT_THREAD  {							\
+	.sp0 = sizeof(init_stack) + (long)&init_stack,			\
+	.vm86_info = NULL,						\
+	.sysenter_cs = __KERNEL_CS,					\
+	.io_bitmap_ptr = NULL,						\
+	.fs = __KERNEL_PERCPU,						\
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS  {							\
+	.x86_tss = {							\
+		.sp0		= sizeof(init_stack) + (long)&init_stack, \
+		.ss0		= __KERNEL_DS,				\
+		.ss1		= __KERNEL_CS,				\
+		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		\
+	 },								\
+	.io_bitmap	= { [0 ... IO_BITMAP_LONGS] = ~0 },		\
+}
+
+#define start_thread(regs, new_eip, new_esp) do {		\
+	__asm__("movl %0,%%gs": :"r" (0));			\
+	regs->fs = 0;						\
+	set_fs(USER_DS);					\
+	regs->ds = __USER_DS;					\
+	regs->es = __USER_DS;					\
+	regs->ss = __USER_DS;					\
+	regs->cs = __USER_CS;					\
+	regs->ip = new_eip;					\
+	regs->sp = new_esp;					\
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS      (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info)                                                 \
+({                                                                     \
+       unsigned long *__ptr = (unsigned long *)(info);                 \
+       (unsigned long)(&__ptr[THREAD_SIZE_LONGS]);                     \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task)                                             \
+({                                                                     \
+       struct pt_regs *__regs__;                                       \
+       __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+       __regs__ - 1;                                                   \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64	(0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+			   0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE 		(test_thread_flag(TIF_IA32) ? \
+				 IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) 	((test_tsk_thread_flag(child, TIF_IA32)) ? \
+				  IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD  { \
+	.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS  { \
+	.x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { 			     \
+	asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0));  \
+	load_gs_index(0);						     \
+	(regs)->ip = (new_rip);						     \
+	(regs)->sp = (new_rsp);						     \
+	write_pda(oldrsp, (new_rsp));					     \
+	(regs)->cs = __USER_CS;						     \
+	(regs)->ss = __USER_DS;						     \
+	(regs)->flags = 0x200;						     \
+	set_fs(USER_DS);						     \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
@ 2007-12-19 10:17   ` Ingo Molnar
  0 siblings, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-19 10:17 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: linux-kernel, akpm, glommer, tglx, ehabkost, jeremy, avi, anthony,
	virtualization, rusty, ak, chrisw, rostedt, hpa, zach, roland


* Glauber de Oliveira Costa <gcosta@redhat.com> wrote:

> What's left in processor_32.h and processor_64.h cannot be cleanly 
> integrated. However, it's just a couple of definitions. They are moved 
> to processor.h around ifdefs, and the original files are deleted. Note 
> that there's much less headers included in the final version.

hm, doesnt apply;

 Applying patch patches/x86-finish-processor-h-integration.patch
 patching file include/asm-x86/processor.h
 Hunk #2 FAILED at 287.
 Hunk #3 FAILED at 311.
 Hunk #4 succeeded at 786 (offset -8 lines).
 2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h

i fixed it up by hand - the result is below - does it look OK to you? 
(Also, could you check latest x86.git whether i've picked up all your 
patches correctly - the reject might be indicative of some missing 
pieces.)

	Ingo

------------>
Subject: finish processor.h integration
From: Glauber de Oliveira Costa <gcosta@redhat.com>

What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.

Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/asm-x86/processor.h |  140 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 137 insertions(+), 3 deletions(-)

Index: linux-x86.q/include/asm-x86/processor.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/processor.h
+++ linux-x86.q/include/asm-x86/processor.h
@@ -7,12 +7,24 @@
 struct task_struct;
 struct mm_struct;
 
+#include <asm/vm86.h>
+#include <asm/math_emu.h>
+#include <asm/segment.h>
 #include <asm/page.h>
-#include <asm/percpu.h>
+#include <asm/types.h>
+#include <asm/sigcontext.h>
+#include <asm/current.h>
+#include <asm/cpufeature.h>
 #include <asm/system.h>
+#include <asm/page.h>
 #include <asm/percpu.h>
+#include <asm/msr.h>
+#include <asm/desc_defs.h>
+#include <linux/personality.h>
 #include <linux/cpumask.h>
 #include <linux/cache.h>
+#include <linux/threads.h>
+#include <linux/init.h>
 
 /*
  * Default implementation of macro that returns current
@@ -285,9 +297,13 @@ union i387_union {
 };
 
 #ifdef CONFIG_X86_32
-# include "processor_32.h"
+/*
+ * the following now lives in the per cpu area:
+ * extern	int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
 #else
-# include "processor_64.h"
+DECLARE_PER_CPU(struct orig_ist, orig_ist);
 #endif
 
 extern void print_cpu_info(struct cpuinfo_x86 *);
@@ -770,6 +786,124 @@ static inline void prefetchw(const void 
 }
 
 #define spin_lock_prefetch(x)	prefetchw(x)
+#ifdef CONFIG_X86_32
+/*
+ * User space process size: 3GB (default).
+ */
+#define TASK_SIZE	(PAGE_OFFSET)
+
+#define INIT_THREAD  {							\
+	.sp0 = sizeof(init_stack) + (long)&init_stack,			\
+	.vm86_info = NULL,						\
+	.sysenter_cs = __KERNEL_CS,					\
+	.io_bitmap_ptr = NULL,						\
+	.fs = __KERNEL_PERCPU,						\
+}
+
+/*
+ * Note that the .io_bitmap member must be extra-big. This is because
+ * the CPU will access an additional byte beyond the end of the IO
+ * permission bitmap. The extra byte must be all 1 bits, and must
+ * be within the limit.
+ */
+#define INIT_TSS  {							\
+	.x86_tss = {							\
+		.sp0		= sizeof(init_stack) + (long)&init_stack, \
+		.ss0		= __KERNEL_DS,				\
+		.ss1		= __KERNEL_CS,				\
+		.io_bitmap_base	= INVALID_IO_BITMAP_OFFSET,		\
+	 },								\
+	.io_bitmap	= { [0 ... IO_BITMAP_LONGS] = ~0 },		\
+}
+
+#define start_thread(regs, new_eip, new_esp) do {		\
+	__asm__("movl %0,%%gs": :"r" (0));			\
+	regs->fs = 0;						\
+	set_fs(USER_DS);					\
+	regs->ds = __USER_DS;					\
+	regs->es = __USER_DS;					\
+	regs->ss = __USER_DS;					\
+	regs->cs = __USER_CS;					\
+	regs->ip = new_eip;					\
+	regs->sp = new_esp;					\
+} while (0)
+
+
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
+#define THREAD_SIZE_LONGS      (THREAD_SIZE/sizeof(unsigned long))
+#define KSTK_TOP(info)                                                 \
+({                                                                     \
+       unsigned long *__ptr = (unsigned long *)(info);                 \
+       (unsigned long)(&__ptr[THREAD_SIZE_LONGS]);                     \
+})
+
+/*
+ * The below -8 is to reserve 8 bytes on top of the ring0 stack.
+ * This is necessary to guarantee that the entire "struct pt_regs"
+ * is accessable even if the CPU haven't stored the SS/ESP registers
+ * on the stack (interrupt gate does not save these registers
+ * when switching to the same priv ring).
+ * Therefore beware: accessing the ss/esp fields of the
+ * "struct pt_regs" is possible, but they may contain the
+ * completely wrong values.
+ */
+#define task_pt_regs(task)                                             \
+({                                                                     \
+       struct pt_regs *__regs__;                                       \
+       __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+       __regs__ - 1;                                                   \
+})
+
+#define KSTK_ESP(task) (task_pt_regs(task)->sp)
+
+#else
+/*
+ * User space process size. 47bits minus one guard page.
+ */
+#define TASK_SIZE64	(0x800000000000UL - 4096)
+
+/* This decides where the kernel will search for a free chunk of vm
+ * space during mmap's.
+ */
+#define IA32_PAGE_OFFSET ((current->personality & ADDR_LIMIT_3GB) ? \
+			   0xc0000000 : 0xFFFFe000)
+
+#define TASK_SIZE 		(test_thread_flag(TIF_IA32) ? \
+				 IA32_PAGE_OFFSET : TASK_SIZE64)
+#define TASK_SIZE_OF(child) 	((test_tsk_thread_flag(child, TIF_IA32)) ? \
+				  IA32_PAGE_OFFSET : TASK_SIZE64)
+
+#define INIT_THREAD  { \
+	.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define INIT_TSS  { \
+	.x86_tss.sp0 = (unsigned long)&init_stack + sizeof(init_stack) \
+}
+
+#define start_thread(regs, new_rip, new_rsp) do { 			     \
+	asm volatile("movl %0,%%fs; movl %0,%%es; movl %0,%%ds": :"r" (0));  \
+	load_gs_index(0);						     \
+	(regs)->ip = (new_rip);						     \
+	(regs)->sp = (new_rsp);						     \
+	write_pda(oldrsp, (new_rsp));					     \
+	(regs)->cs = __USER_CS;						     \
+	(regs)->ss = __USER_DS;						     \
+	(regs)->flags = 0x200;						     \
+	set_fs(USER_DS);						     \
+} while (0)
+
+/*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+#define thread_saved_pc(t) (*(unsigned long *)((t)->thread.sp - 8))
+
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.sp0 - 1)
+#define KSTK_ESP(tsk) -1 /* sorry. doesn't work for syscall. */
+#endif /* CONFIG_X86_64 */
+
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-19 10:17   ` Ingo Molnar
  (?)
  (?)
@ 2007-12-19 12:15   ` Glauber de Oliveira Costa
  -1 siblings, 0 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-19 12:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: ehabkost, linux-kernel, Glauber de Oliveira Costa, chrisw,
	anthony, hpa, akpm, virtualization, tglx, roland, ak

On Dec 19, 2007 8:17 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Glauber de Oliveira Costa <gcosta@redhat.com> wrote:
>
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> hm, doesnt apply;
>
>  Applying patch patches/x86-finish-processor-h-integration.patch
>  patching file include/asm-x86/processor.h
>  Hunk #2 FAILED at 287.
>  Hunk #3 FAILED at 311.
>  Hunk #4 succeeded at 786 (offset -8 lines).
>  2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h
>
> i fixed it up by hand - the result is below - does it look OK to you?
> (Also, could you check latest x86.git whether i've picked up all your
> patches correctly - the reject might be indicative of some missing
> pieces.)

Your fix is okay. The other patches seems to be all there. The reason
for this is that
it conflicts with Roland's (welcome) i387 patches.


-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-19 10:17   ` Ingo Molnar
  (?)
@ 2007-12-19 12:15   ` Glauber de Oliveira Costa
  2007-12-19 13:45     ` Ingo Molnar
  2007-12-19 13:45     ` Ingo Molnar
  -1 siblings, 2 replies; 18+ messages in thread
From: Glauber de Oliveira Costa @ 2007-12-19 12:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Glauber de Oliveira Costa, linux-kernel, akpm, tglx, ehabkost,
	jeremy, avi, anthony, virtualization, rusty, ak, chrisw, rostedt,
	hpa, zach, roland

On Dec 19, 2007 8:17 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Glauber de Oliveira Costa <gcosta@redhat.com> wrote:
>
> > What's left in processor_32.h and processor_64.h cannot be cleanly
> > integrated. However, it's just a couple of definitions. They are moved
> > to processor.h around ifdefs, and the original files are deleted. Note
> > that there's much less headers included in the final version.
>
> hm, doesnt apply;
>
>  Applying patch patches/x86-finish-processor-h-integration.patch
>  patching file include/asm-x86/processor.h
>  Hunk #2 FAILED at 287.
>  Hunk #3 FAILED at 311.
>  Hunk #4 succeeded at 786 (offset -8 lines).
>  2 out of 4 hunks FAILED -- rejects in file include/asm-x86/processor.h
>
> i fixed it up by hand - the result is below - does it look OK to you?
> (Also, could you check latest x86.git whether i've picked up all your
> patches correctly - the reject might be indicative of some missing
> pieces.)

Your fix is okay. The other patches seems to be all there. The reason
for this is that
it conflicts with Roland's (welcome) i387 patches.


-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-19 12:15   ` Glauber de Oliveira Costa
  2007-12-19 13:45     ` Ingo Molnar
@ 2007-12-19 13:45     ` Ingo Molnar
  1 sibling, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-19 13:45 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: ehabkost, linux-kernel, Glauber de Oliveira Costa, chrisw,
	anthony, hpa, akpm, virtualization, tglx, roland, ak


* Glauber de Oliveira Costa <glommer@gmail.com> wrote:

> > i fixed it up by hand - the result is below - does it look OK to 
> > you? (Also, could you check latest x86.git whether i've picked up 
> > all your patches correctly - the reject might be indicative of some 
> > missing pieces.)
> 
> Your fix is okay. The other patches seems to be all there. The reason 
> for this is that it conflicts with Roland's (welcome) i387 patches.

ah, indeed - i forgot about that interaction. Your patches passed a
few hundred random builds and bootups meanwhile so i think they are
now 100% Perfect (tm) :-)

	Ingo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-19 12:15   ` Glauber de Oliveira Costa
@ 2007-12-19 13:45     ` Ingo Molnar
  2007-12-19 13:45     ` Ingo Molnar
  1 sibling, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2007-12-19 13:45 UTC (permalink / raw)
  To: Glauber de Oliveira Costa
  Cc: Glauber de Oliveira Costa, linux-kernel, akpm, tglx, ehabkost,
	jeremy, avi, anthony, virtualization, rusty, ak, chrisw, rostedt,
	hpa, zach, roland


* Glauber de Oliveira Costa <glommer@gmail.com> wrote:

> > i fixed it up by hand - the result is below - does it look OK to 
> > you? (Also, could you check latest x86.git whether i've picked up 
> > all your patches correctly - the reject might be indicative of some 
> > missing pieces.)
> 
> Your fix is okay. The other patches seems to be all there. The reason 
> for this is that it conflicts with Roland's (welcome) i387 patches.

ah, indeed - i forgot about that interaction. Your patches passed a
few hundred random builds and bootups meanwhile so i think they are
now 100% Perfect (tm) :-)

	Ingo

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2007-12-19 13:46 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-18 20:04 [PATCH] finish processor.h integration Glauber de Oliveira Costa
2007-12-18 20:04 ` Glauber de Oliveira Costa
2007-12-18 20:54 ` Frans Pop
2007-12-18 21:00   ` Glauber de Oliveira Costa
2007-12-18 21:00   ` Glauber de Oliveira Costa
2007-12-18 21:02     ` Ingo Molnar
2007-12-18 21:02     ` Ingo Molnar
2007-12-18 21:32     ` Frans Pop
2007-12-19  2:56       ` Glauber de Oliveira Costa
2007-12-19  2:56       ` Glauber de Oliveira Costa
2007-12-18 21:32     ` Frans Pop
2007-12-18 20:54 ` Frans Pop
2007-12-19 10:17 ` Ingo Molnar
2007-12-19 10:17   ` Ingo Molnar
2007-12-19 12:15   ` Glauber de Oliveira Costa
2007-12-19 13:45     ` Ingo Molnar
2007-12-19 13:45     ` Ingo Molnar
2007-12-19 12:15   ` Glauber de Oliveira Costa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.