public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] finish processor.h integration
@ 2007-12-18 20:04 Glauber de Oliveira Costa
  2007-12-18 20:54 ` Frans Pop
  2007-12-19 10:17 ` Ingo Molnar
  0 siblings, 2 replies; 9+ 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] 9+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:04 [PATCH] finish processor.h integration Glauber de Oliveira Costa
@ 2007-12-18 20:54 ` Frans Pop
  2007-12-18 21:00   ` Glauber de Oliveira Costa
  2007-12-19 10:17 ` Ingo Molnar
  1 sibling, 1 reply; 9+ 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] 9+ 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:02     ` Ingo Molnar
  2007-12-18 21:32     ` Frans Pop
  0 siblings, 2 replies; 9+ 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] 9+ 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:32     ` Frans Pop
  1 sibling, 0 replies; 9+ 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] 9+ 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:32     ` Frans Pop
  2007-12-19  2:56       ` Glauber de Oliveira Costa
  1 sibling, 1 reply; 9+ 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] 9+ 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
  0 siblings, 0 replies; 9+ 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] 9+ messages in thread

* Re: [PATCH] finish processor.h integration
  2007-12-18 20:04 [PATCH] finish processor.h integration Glauber de Oliveira Costa
  2007-12-18 20:54 ` Frans Pop
@ 2007-12-19 10:17 ` Ingo Molnar
  2007-12-19 12:15   ` Glauber de Oliveira Costa
  1 sibling, 1 reply; 9+ 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] 9+ 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
  0 siblings, 1 reply; 9+ 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] 9+ 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
  0 siblings, 0 replies; 9+ 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] 9+ messages in thread

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

Thread overview: 9+ 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:54 ` Frans Pop
2007-12-18 21:00   ` Glauber de Oliveira Costa
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 10:17 ` Ingo Molnar
2007-12-19 12:15   ` Glauber de Oliveira Costa
2007-12-19 13:45     ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox