On Fri, 2007-04-06 at 08:39 -0700, H. Peter Anvin wrote:
> I will, unless Rusty does, first. No desire to step on each other.
Oh no, please, after you!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Andi Kleen wrote:
On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added
On Thu, Apr 05, 2007 at 06:06:16PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >No processor.h is such a hodgepodge of unrelated stuff that any
> >splitting up is a good thing.
> >
>
> Fair enough. However, I'd still like to see the X86_CR* constants
> moved, too (and constants added
On Thu, 2007-04-05 at 18:06 -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> > No processor.h is such a hodgepodge of unrelated stuff that any
> > splitting up is a good thing.
> >
>
> Fair enough. However, I'd still like to see the X86_CR* constants
> moved, too (and constants added for
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added for at least CR0 as well.)
-hpa
-
To unsubscribe from this list: send t
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> >That patch got dropped, and replaced by one which pulled all the flags
> >definitions out of
> >
>
> Saw that a little too late :)
>
> In general, it would be nice if the various CPU constants wer
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of
Saw that a little too late :)
In general, it would be nice if the various CPU constants were all
defined in one place, so I'd rather suggest protecting the appropriate
part
H. Peter Anvin wrote:
> Rusty Russell wrote:
>
>> There is now more than one place where we use the fact that bit 9 of
>> eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
>> 512 so it can be used in asm, too.
>>
>
> How about defining all the other EFLAGS in one place?
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
-hpa
-
To unsubscribe from this list
On Thu, 2007-03-22 at 14:16 +1100, Rusty Russell wrote:
> There is now more than one place where we use the fact that bit 9 of
> eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
> 512 so it can be used in asm, too.
Belay this: there's a X86_EFLAGS_IF in asm/processor.h which
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
--- a/arch/i386/lguest/lguest.c
+++ b/arch/i386/lguest/lguest.c
@@ -107,9
11 matches
Mail list logo
